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Abstract 

Software  ar'rhiiectures  increase  productivity  when  used  as  the  basis  for  devel¬ 
oping  applications  in  a  problem  domain.  This  thesis  describes  the  creation  of 
Easy_Sim,  an  object-oriented  software  architecture  for  visual  simulation  sys¬ 
tems,  and  its  corresponding  implementation  as  an  application  framework  in 
Ada  9X.  The  research  built  upon  ObjectSim,  an  existing  object-oriented  simu¬ 
lation  architeaure  Implemented  as  a  C+-?  application  framework.  Both  Qbject- 
Sim  and  Easy_Sim  operate  on  Silicon  Graphics  platforms  and  use  the  IRIS  Per¬ 
former  graphics  programming  librar>’.  Easy_Sim  is  implemented  using  ver¬ 
sion  1.83  of  the  GNAT  compiler. 

The  investigation  for  this  thesis  involved  honing  ObjectSim's  design. 
Implementing  the  improved  result  in  both  C++  and  Ada  9X,  and  developing 
applications  to  compare  the  two  versions.  The  study  achieved  two  main  objec¬ 
tives:  producing  Easy_Sim  as  an  improved  visual  simulation  system  architec¬ 
ture  by  building  on  ObjeaSim’s  experience,  and  producing  a  visual  simulation 
system  application  from  Easy_Sim  In  Ada  9X  that  performs  at  a  level  compara¬ 
ble  to  the  same  application  built  in  C+-f. 
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EASY^SIM:  A 

VISUAL  SIMULATION  SYSTEM 
SOFTWARE  ARCHITECTURE 
WITH  AN 
ADA9X 

APPLICATION  FRAMEWORK 


I.  Introduction 


1.1  Background 

A  visual  simulation  Is  a  system  in  which  an  operator  is  placed  in  a  computer 
generated  environment  and  presented  with  graphical  stimuli  mimicking  ac¬ 
tual  objects  and  events.  These  systems  have  numerous  commercial,  militar}', 
and  recreational  applications  because  they  provide  safe,  inexpensive,  and  ef¬ 
ficient  means  of  training  personnel,  serve  as  a  logical  test  bed  for  innovative 
ideas,  and  have  tremendous  entenainment  value,  One  of  the  most  familiar  vi¬ 
sual  simulation  systems  is  the  flight  simulator,  in  which  pilots  step  into  an  ar¬ 
tificial  cockpit  and  practice  flying  techniques  without  leaving  the  ground. 
The  simulator  allows  the  pilots  to  gain  invaluable  practice  and  train  for  ad¬ 
verse  conditions  without  risking  their  safety,  putting  stress  on  real  airplanes, 
or  wasting  valuable  resources. 

While  there  is  no  doubt  that  visual  simulation  systems  are  beneficial, 
their  graphics-intensive  software  nature  has  presented  numerous  challenges 
throughout  the  years  for  system  developers.  The  constantly  increasing  com¬ 
plexity  of  the  simulated  systems  has  led  to  a  corresponding  increase  in  the 
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software  complexity  of  the  simulators.  In  order  to  manage  this  complexity 
more  easily,  the  building  of  reusable  base  designs,  or  software  architectures, 
has  begun  in  earnest  by  the  makers  of  visual  simulation  systems.  This  trend  is 
not  unique  to  simulators;  software  developers  in  other  problem  areas-,  or  do¬ 
mains,  are  also  designing  architectures  to  create  solid  foundations  for  their 


systems. 

Software  architectures  can  lead  to  many  improvements  in  the  develop¬ 
ment  of  software  s>’stems  within  a  domain.  Because  an  architecture  promotes 
reuse  at  the  design  level,  systems  developers  do  not  have  to  devote  effort  to 
analyzing  and  designing  basic  structures  ever>'  time  a  new  application  of  the 
system  is  needed.  The  existing  grotndwork  allows  developers  to  concentrate 
more  of  their  work  on  problem  specific  areas,  and  cuts  down  on  overall  pro- 
durtion  time  and  cost  {Law94,3].  The  software  architecture  also  makGS  the  re¬ 
sultant  system  more  maintainable  and  supportable,  because  changes  can  be 
incorporated  more  easily.  By  finding  the  place  in  the  base  design  where  a 
change  will  occur,  Its  effeas  throughout  the  entire  system  can  be  determined 
and  the  impact  of  the  change  can  be  minimized.  This  ability  to  make  changes 
more  easily  also  leads  to  the  practice  of  rapid  prototyping,  In  which  stepwise 
refinements  are  made  to  the  implementation  until  Che  end  result  reaches  pro¬ 
duction  quality.  Rapid  prototyping  allows  system  u.sers  to  become  more  In¬ 
volved  in  the  development  process,  giving  them  more  control  over  the  final 
outcome. 


1.2  Problem  History 


The  research  for  this  thesis  builds  upon  recent  developments  in  creating  soft¬ 
ware  architectures  for  the  visual  simulation  system  domain.  It  primarily  adds 
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to  recent  work  accomplished  in  the  Graphics  Laboratory  (Lab)  of  the  Air  Force 
Institute  of  Technology  (AFIT).  This  graduate  research  Involves  distributed 
simulators,  which  allow  a  more  realistic  training  situation  by  incorporating 
physically  separated  actors  into  a  battlefield  situation.  The  interaction  be¬ 
tween  the  various  simulators  is  accomplished  by  means  of  network  connec¬ 
tions  and  established  communication  protocols.  As  part  of  this  research,  the 
AFIT  Graphics  Lab  has  recently  produced  a  virtual  cockpit  for  the  F-15E 
fighter  [Eri93,  Ger93,  Dia94],  a  space  modeler  [Kun93,  Van94],  a  commander's 
situational  battle  bridge  (Sol93,  WiI93,  Kes94,  Roh94],  and  an  air  combat  de¬ 


briefing  tool  for  the  Air  Force  s  Red  Flag 


AVAr^co 


T-3V>1a 


gives  the  details  of  the  research  projects  completed  «n  1 993. 


Because  these  projects  and  their  predecessors  are  visual  simulation 


systems,  they  perform  many  of  the  same  tasks.  Historically,  these  common 
tasks  were  re-accomplished  for  each  new  application  in  the  Graphics  Lab. 


Under  an  Initiative  started  in  1992,  this  unfortunate  and  inefficient  problem 
\»as  addressed  by  creating  a  software  architecture  dubbed  ObjcCtSiiu.  This  de¬ 
sign  provided  the  common  strtKture  for  each  of  the  applications  and  allowed 
the  different  developers  to  concentrate  more  heavily  on  the  unique  aspects  of 
their  particular  applications.  ObjectSim  also  served  as  the  focus  of  Mark  Sny¬ 
der's  graduate  thesis  ILaw94,  Sny93]. 

The  implementation  of  ObjeaSim  exists  at  a  high  level  of  generality,  and 
can  be  used  to  create  diverse  simulation  systems,  as  evidenced  by  the  four 
applications.  ObjectSim  is  also  a  completely  objea-oriented  technology.  In  or¬ 
der  to  produce  an  application,  developers  must  create  their  own  versions  of 
the  structure  by  inheriting  and  deriving  from  the  basic  design.  Because  the 
ObjectSim  implementation  is  abstract  and  can  only  ser/e  as  the  basis  for  sys^ 
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Table  1.  AFIT  Graphics  lab  Research  Projeas  for  1993 


IVojrcl 

D«\cription 

RMfurch  Guab, 

Vinual  Cockpit 
fErich93] 

|Gef93] 

Immersive  llighi  simulator  lor  an 
F-15E 

■  Research  inexpensive 
alternative  to  domed 
simulator 

•  Build  man-in-the-loopDlS 
platform 

•  Study  modeling  of 
advanced  weapons  system 

S>'nlhct]C  Battle  Bridjic 

lSolt793] 

p\'il931 

Immersivc/Console  based  com- 
m.mder's  eye  vieu  of  battlefield 

-  Research  immersive 
interface  techniques  for 
commander 

-  Study  expert  computer 
situational  analysis 

•  Study  situational 

representation  techniques 
for  battlefield 

-  Study  usa  interface 
techniques  for  effeaive 
user  view  control 

Satellite  Modeler 
lKuaz93] 

Immcrsivc/console  simulation  lor 
analysis  of  satcUiics 

•  Represent  single  orbit.s  or 
constellations 

•  Study  immersive  interface 
into  satellite  simulation 

-  Interface  satellite  data 
onto  DIS  simulations 

Red  Flag  Display  Tool 
[Gafd931 

Coasole  based  debnefing/display 
tool  for  Air  Force  exercises 

•  Study  user  imcrfacc  for 
debriefing  .system 
-  Interface  live  or  recorded 
exercise  data  onto  DIS 

tem  applications,  It  Is  called  an  application  framework  lSny93,12].  The  reuse  of 
ObjectSlm's  Implemented  code  resulted  in  a  vast  increase  in  the  production  rate 
of  visual  simulation  sj'stems  In  the  AFIT  Graphics  Lab  iSny93,7B-B2]. 

Unfortunately,  ObjectSlm  does  also  have  some  drawbacks.  Most  notable 
is  Its  heav>'  reliance  upon  underlying  software  libraries  and  hardware  pro¬ 
duced  by  Silicon  Graphics,  Inc.  (SGI).  The  realistic  speeds,  or  frair.e  rates,  with 
which  ObjectSlm  applications  are  able  to  draw,  or  render,  visual  simulations 
can  be  attributed  almost  entirely  to  Us  use  of  SGl’s  IRIS  Performer  (Perfermer) 
graphics  application  development  environment  [McL92,  Kar54].  ObjectSim  is 


therefore  not  system  independent,  or  portable.  Another  indirect  consequence 
of  ObjectSim's  dependence  on  its  SG!  environment  is  Us  implementation  in  C+-. 
This  choice  was  necessary  to  allow  object-oriented  eAtension  and  to  achieve 
compatibility  with  Performer,  whose  interface  is  written  in  C,  Many  of  the  vi¬ 
sual  simulation  system  application  developers  have  expressed  that  they  could 
have  been  more  productive  had  they  not  had  to  fight  the  cry-ptic  intricacies  of 
C++  [Law94,7]. 

1.3  Research  Motivation 

Ada  is  preferable  to  C+-  as  an  implementation  language  for  many  life  cycle 
software  engineering  reasons.  These  factors  all  cause  Ada  to  be  more  expen¬ 
sive  in  terms  of  cost  and  time  in  the  initial  phase  of  a  software  project,  but 
long  run  benefits  justify  these  costs  over  the  I  ifetime  of  the  system.  Ada  code 
is  inherently  more  readable  than  C-+  code,  due  to  the  more  verbose  and  ex¬ 
plicit  nature  of  Ada  syntax.  More  readable  code  is  necessarily  more  under¬ 
standable,  and  in  an  ?rena  in  which  application  developers  build  from  a  com¬ 
mon  framework,  it  is  vital  that  they  can  comprehend  that  framework.  More 
understandable  code  also  contributes  to  Ada's  higher  modifiability,  as  the  lo¬ 
cations  of  changes  are  more  readily  apparent,  and  th^’  effects  of  the  changes 
throughout  the  entire  program  are  more  easily  determined.  In  contrast,  the 
cryptic  notation  of  the  C  language  which  underlies  all  C++  code  is  notorious  for 
PiOducing  unexpected  results  (Feu82]. 

Reliability  is  also  much  harder  to  achieve  in  C++  than  Ada.  C++  cannot 
dodge  Its  C  underpinnings.  Us  weaker  data  typing  facilities,  or  its  currently 
non-standard  implementation  of  exception  handling,  all  factors  that  con¬ 
tribute  to  Us  lesser  reliability.  Even  main  proponents  of  C++  acknowledge  its 
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disadvantages  tn  this  area.  P.  J.  Piauger.  the  author  of  the  ANSI  C  standard,  has 
stated,  "Beyond  50,000  lines  of  C,  you’d  better  take  a  hard  look  at  converting  to 
C+>.  Beyond  100,000  lines,  you  should  probably  be  ceding  in  Ada"  [P!a89, 
Pla94]. 

Mark  Snyder  was  well  aware  of  the  benefits  of  .Ada  when  he  imple¬ 
mented  ObjectSim,  but  he  also  had  good  reasons  to  choose  C+-.  First,  C+4  was 
compatible  with  the  underlying  C  tools  of  the  SGI  environment.  Given  that  six 
other  concurrent  thesis  efforts  In  the  AFIT  Graphics  Lab  relied  on  his  work, 
Snyder  did  not  have  the  time  to  finagle  compatibility  with  Ada.  Second,  Snyder 
needed  a  language  that  supported  the  object-oi’iented  extensibility  he  envi¬ 
sioned  for  ObjectSim.  While  Ada  9X  supports  this  feature,  it  was  not  yet  avail¬ 
able.  Snyder  could  only  consider  using  Ada  83,  which  has  no  facility  for  ex¬ 
tensibility.  His  choice  for  ObjectSim  was  therefore  obvious. 

Ada  9X  has  now  become  available  through  the  development  of  prelimi¬ 
nary  compilers  for  the  language.  Although  they  are  not  yet  complete,  they  do 
provide  support  for  objea-orlented  extensibility  and  many  other  features  that 
can  enhance  ObjectSim.  Five  more  thesis  efforts  in  the  AFIT  Graphics  Lab 
have  evolved  the  four  applications,  but  they  use  Snyder's  C—  version  of  the 
ObjectSim  framework.  The  research  on  Easy^Sim,  the  Ada  9X  version  of  the 
framework,  the  'efore  has  been  free  to  experiment  with  different  versions  of 
the  implementation  of  the  Easy_Sim  archlteaure. 

1.4  Scope  of  Research 

This  research  has  two  primary  goals;  to  develop  a  substantially  improved 
Easy_Slm  archlteaure  using  the  knowledge  gained  from  work  accomplished 
with  ObjectSim,  and  to  demonstrate  that  a  visual  simulation  system  application 
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framework  can  be  implemented  using  Ada  9X  and  provide  capabilities  equal  to 
or  better  than  a  similarly  designed  C+*  framework.  The  end  result  of  the  effort 
is  therefore  to  demonstrate  concept  feasibility  by  producing  an  application 
using  the  Easy_Sirn  framework,  and  shoxving  that  the  application’s  perfor¬ 
mance  has  not  suffered.  A  C-+  implementation  of  the  Easy_Sim  architecture  is 
maintained  with  the  same  functionality  as  the  Ada  9X  version.  This  version 
serves  as  a  control  so  that  a  fair  comparison  is  still  possible  if  ObjectSim  and 
Easj'_Sim  diverge  substantially.  Three  questions  were  investigated  in  this  re¬ 
search. 

The  first  question  investigated  the  design  of  ObjectSim..  Mark.  Snyder's 
domain  analysis  consisted  of  examining  components  of  each  of  the  four  appli¬ 
cations  under  development  during  his  tenure  in  the  AFIT  Graphics  Lab,  and 
determining  which  of  these  components  might  be  useful  to  other  applications. 
Even  with  this  localized  approach,  Snyder’s  time  constraints  did  not  allow  Ob- 
jertSlra  to  encompass  all  of  the  functionality  originally  envisioned.  Most  no¬ 
tably  absent  is  the  handling  of  network  interactions  between  the  distributed 
simulators  tSny93,96-99]. 

The  second  question  to  Investigate  in  producing  a  working  application 
was  the  implementation  of  the  software  architecture  design  in  Ada  9X.  This 
question  scrutinized  the  method  for  migration  from  C++  to  Ada  9X  structures. 
This  question  also  Involved  ensuring  that  the  proper  tools  were  available  to 
assist  in  the  code  production,  including  an  Ada  9X  compiler  and  bindings  to  the 
underlying  SGI  environment. 

Once  the  Easy_Sim  framewo’-k  was  built,  the  final  question  Investigated 
the  building  of  an  application  using  Ada  9X.  Mark  Snyder  describes  example 
applications  In  the  ObjeaSim  Application  Developer's  Manual  [S.ny93,.App.A], 


Implementing  these  sample  programs  in  Ada  9X  and  analyzing  their  perfor¬ 
mance  demonstrated  the  ability  of  the  Easy_Sim  framework. 

Although  it  would  be  beneficial  to  divorce  Eas5'_Sim  from  Its  reliance  on 
the  SGI  environment,  there  are  reasons  this  research  did  not  entertain  the 
idea.  A  high  level  comparison  is  a  primar>'  focus  of  this  study,  and  it  is  there¬ 
fore  important  that  the  frameworks  be  implemented  similarly.  The  SGI  envi¬ 


ronment  is  utilized  because  of  its  availability’ 
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proven  capability  for  efficiently  rendering  graphics  applications. 


1.5  Methodology  Overview 


Each  of  the  three  questions  outlined  in  the  previous  section  corresponds  to  a 
set  of  actions  that  influenced  the  development  of  the  Easy_Sim  architecture 
and  framework,  as  well  as  example  applications. 

The  first  question,  investigating  ObjectSim’s  design,  corresponded  to  the 
domain  analysis  of  the  problem.  The  original  analysis  of  ObjectSim  was  scru¬ 
tinized  for  inconsistencies  and  deficiencies,  and  any  changes  deemed  neces¬ 
sary  or  beneficial  were  incorporated  into  the  design  of  Easy^SIm, 

The  second  investigative  question  Implemented  the  results  of  the  do¬ 
main  analysis  in  Ada  9X.  Different  strategies  for  this  process  were  considered, 
with  an  emphasis  on  reusing  as  much  existing  code  as  possible*  The  GRAT 
compiler  was  used  to  test  these  strategies.  The  first  hurdle  in  the  implementa¬ 
tion  process  was  the  creation  of  Ada  bindings  to  the  Performer  Iibrar>'.  Luck¬ 


ily,  visual  simulation  system  developers  at  Silicon  Graphics  also  have  a  keen 


interest  in  Ada  9X.  and  they  created  a  preliminary  set  of  bindings,  as  well  as  a 


port  of  the  GNAT  compiler.  They  generously  agreed  to  contribute  these  prod- 


uas  to  this  research  effort. 
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The  final  investigative  question  compared  the  ObjectSim  and  Easy^Sim 
frameworks  by  demonstrating  similar  applications  using  each  version.  These 
demonstrations  were  initially  accomplished  by  building  Ada  9X  versions  of  the 
ObjeaSim  example  applications  [Sny93.AppA].  Because  the  ObjectSim  and 
Easy_Sim  implementations  differ,  comparing  them  is  unfair,  and  the  C-+  ver¬ 
sion  ol  the  Easy_Slm  framework  was  used  as  a  reference  point. 

In  the  discussion  above,  it  mistakenly  appears  that  the  research  oc¬ 
curred  in  three  large  chunks.  In  reality,  investigation  of  the  questions  was 
performed  repetitively  in  a  rapid  prototyping  fashion,  Incorporating  more  of 


the  solution's  functionality  with  each  i 


AViUii. 
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allowed  development  of  a  working  application  earlier  in  the  process.  Each  it¬ 


eration  corresponded  to  the  addition  of  another  feature  in  the  architecture, 


with  the  existing  ObjectSim  example  applications  serving  as  pr 


1.6  Research  Environment 


This  research  effort  used  the  equipment  and  tools  located  in  the  .AFIT  Graphics 
Lab.  The  SGI  environment  consists  of  various  proprietary  hardware  and  soft¬ 
ware  systems.  The  machines  include  interconnected  Indigo,  Indigo^,  VGXT, 
and  Ontoc/Reality  Engine^  computer  systems,  with  most  of  the  work  and  all  of 
the  results  collection  accomplished  on  the  four-processor  On>’x  known  as 
Leonardo.  The  machines  use  version  5.2  of  SGI’s  IRIX  Incarnation  of  the  UNIX 
operating  system.  Version  1.2  of  the  IRIS  Performer  library  [Har94j  and  ver¬ 
sion  5.2  of  SGI's  Graphics  Library'  [McL91]  enabled  the  graphics  processing  to 
occur  at  realistic  rates.  Version  3.2.1  of  SGI's  C+-  preprocessing  compiler  was 
responsible  for  compiling  the  C++  code. 


The  Ada  9X  code  compilation  occurred  courtesy  of  GNAT,  the  Ada  addition 
to  the  Free  Software  Foundation's  gcc  compiler  family.  A  team  at  New  York 


University  (NYU)  produces  this  sharevvsre  ccrTipllcr  with  the  support  of  the 
Ada  Joint  Program  Office.  .Although  the  GNAT  compiler  is  not  complete,  it  has 
continually  evolved  and  matured  throughout  the  endurance  of  this  thesis.  The 
res'ilts  presented  were  compiled  with  version  1.83. 

Outside  of  the  Graphics  Lab,  the  contributions  of  various  indiviciuals  was 


Instrumental  in  the  progression  of  this  thesis.  SGl's  .Ada  team  provided  solu¬ 
tions  to  binding  problems  and  ported  the  GNAT  compiler  to  the  SGI  systems. 
The  GNAT  development  team  at  NYU  graciously  responded  to  inquiries  about 


the  compiler  and  Its  maturity. 


1.7  Document  Overview 


This  research  investigated  developing  a  new  version  of  a  visual  simulation 
system  sofnvare  architecture  and  Implementing  that  architecture  as  an  appli¬ 
cation  framework  in  the  Ada  9X  programming  language.  The  history,  ratio¬ 
nale,  focus,  and  methods  for  this  effort  have  been  outlined  throughout  this 
chapter.  The  remaining  chapters  describe  the  research  completely. 

Chapter  II  details  background  topics  pertinent  to  this  effort.  It  covers 
object-oriented  methodologies  and  programming  language.s,  software  archi¬ 
tecture  and  application  framework  theory,  industrial  simulation  architectures, 
the  basics  of  the  SGI  environment,  and  the  ObjectSim  architecture.  Chapter  III 
illustrates  the  changes  made  to  the  ObjectSim  dom.aln  analysis  and  design  to 
produce  Easy_Slm.  Chapter  presents  the  techniques  used  in  the  migration 
from  the  C-r+  implementation  of  ObjectSim  to  the  Ada  9x  Implementation  of 
Easy_Sim.  Chapter  V  describes  the  development  of  visual  simulation  system 
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applications  built  from  Easy_Sim.  Chapter  YI  analyzes  the  results  of  the  com¬ 
parison  of  the  different  versions  of  the  architecture.  Finally,  Chapter  VII 
summarizes  the  research  accomplishments  and  suggests  areas  for  improve¬ 
ments  and  future  study. 
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n  Overview  of  Current  Research 


Before  discussion  of  the  details  of  this  thesis  occurs,  this  chapter  presents 
various  prerequisite  topics.  The  chapter  is  constructed  so  that  the  reader  can 
easily  skip  any  of  the  concepts  with  which  he  or  she  is  already  familiar. 

The  first  seaion  of  this  chapter  gives  an  Introduction  to  objea-oriented 
software  development  by  looking  at  different  related  topics.  It  first  covers  the 
overall  concepts  that  define  the  term  cbject-orscntcd,  and  then  discusses  the 
implementation  of  the  object-oriented  methodology  in  both  the  C-f+  and  Ada  9X 
programming  languages.  The  final  portions  of  the  first  section  cover  the 
Rumbaugh  technique  for  describing  object-oriented  analyses  and  designs,  and 
the  ROMAN-9X  method  for  developing  Ada  9X  code  from  Rumbaugh  diagrams. 

The  second  section  of  this  chapter  defines  software  archlteaures,  and 
the  third  section  analyaes  these  architectures  as  they  are  used  within  the 
simulation  industry  toda}'.  The  fourth  section  describes  the  Silicon  Graphics 
Performer  library’,  and  the  final  section  Introduces  ObjectSim,  the  architec¬ 
ture  upon  which  Easy^im  is  based. 

2.1  Object-Oriented  Concepts 


Object-oriented  methods,  including  analysis  and  design  techniques  as  well  as 
programming  languages,  have  certain  characteristics  that  give  them  a  clear 
advantage  in  the  software  development  process.  Perhaps  the  most  obvious  of 
these  is  their  reliance  on  an  objective  problem  view  instead  of  the  more  tradi¬ 
tional  functional  Mew.  People  are  more  easily  able  to  identify  the  concrete 
players,  or  objects,  involved  in  solving  a  problem  than  they  are  able  to  Imag¬ 
ine  the  abstract  processes  needed  to  achieve  a  result.  Object-oriented  pro- 
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gramming  paradigms  capitalize  on  this  more  intuitive  way  of  attacking  a 
problem,  and  have  been  more  readily  received  because  of  it.  Software  devel¬ 
opers  first  determine  which  objects  they  need  in  a  problem,  and  then  figure 
the  processes,  or  operations  that  go  with  each  object. 

While  an  object-oriented  method  may  be  more  intuitive,  it  would  be 
useless  if  it  did  not  lend  itself  to  the  production  of  systems  that  adhere  to  the 
common  goals  of  software  engineering  [RosTS].  Luckily,  maintainable,  un¬ 
derstandable,  reliable,  and  efficient  code  can  be  readily  produced  through  ob¬ 
ject-oriented  programming  techniques.  Technically,  most  experts  agree  that 
there  are  four  major  features  that  m.ake  a  m.ethodology  object-oriented:  ab¬ 
straction,  encapsulation,  inheritance,  and  polymorphism  lBoo94,  Rum91, 
Str91].  Each  of  these  features  contributes  in  the  effort  to  attain  the  goals  of 
software  engineering. 

Abstraction  is  the  separation  of  an  object's  specified  functionality  from 
its  implementation.  One  programmer  writes  a  set  of  routines  with  a  well-de¬ 
fined  interface,  and  another  programmer  easily  integrates  that  code  into  her 
own  work  with  simple  calls.  The  caller's  code  is  unaffected  by  changes  in  the 
implementation,  and  she  can  therefore  be  completely  oblivious  of  the  rou¬ 
tine's  implementation.  This  feature  is  preferable  in  a  large  project,  in  fact, 
because  it  is  impossible  for  a  single  programmer  to  understand  the  entire  sys¬ 
tem.  Types  that  use  abstraction  have  historically  been  termed  abstract  data 
types  (ADTs),  and  to  effectively  use  this  powerful  concept,  the  programmer 
must  learn  to  rely  on  what  a  piece  of  code  does,  instead  of  how  exactly  it  work.s, 
Ironically  then,  abstraction  allows  software  developers  to  accomplish  more  by 
understanding  less.  The  reality  of  this  situation  makes  abstraction  the  key  to 
objects. 
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The  second  major  feature  of  object-oriented  languages,  encapsulation, 
builds  upon  abstraction.  Encapsulation  is  also  often  commonly  referred  to  as 
information  hiding.  Where  abstraction  logically  separates  what  happens  with 
an  object  from  how  it  occurs,  encapsulation  physically  divorces  the  two  ideas. 
A  piece  of  code’s  implementation  is  no  longer  simply  irrelevant  to  a  client 
programmer,  it  is  also  inaccessible,  grouped  together  and  hidden  within  the 
code’s  innards.  There  are  nvo  basic  scenarios  where  this  is  invaluable  for  a 
system's  reliability.  The  first  is  to  prevent  hackers,  who  know  the  intricacies 
of  the  implementation,  from  intentionally  try’ing  to  affect  the  outcome  of  a 
routine.  Tricks  or  kludges  that  they  think  enhance  the  code  may  unforiu- 
nately  Introduce  errors  into  the  work  of  other  client  programmers.  The  sec¬ 
ond  scenario  occurs  when  a  maintenance  programmer  is  charged  with  en¬ 
hancing  a  piece  of  code,  but  only  partly  understands  its  implementation.  The 
programmer  makes  some  minor  clianges  in  a  module  that  seem  to  achieve  the 
desired  result.  VNTiile  he  is  not  Intentionally  trying  to  change  the  overall  im¬ 
plementation  of  the  system,  he  may  inadvertently  end  up  doing  so  and  once 
again  affea  the  whole  system.  Encapsulation  is  therefore  a  feature  that  can 
increase  reliability  by  grouping  all  related  code  together.  It  ser\’es  as  a  safety 
mechanism  preventing  both  malicious  and  accidental  breaches  of  an  abstrac- 


/nherifance  is  the  third  major  feature  of  object-oriented  languages.  It 
follows  from  the  real  world  model  of  objects,  where  one  object  can  be  very 
similar  to  another  objea,  only  with  a  few  new  additional  details.  .A.n  FM  stereo 
radio,  for  instance.  Is  an  FM  radio  with  left  and  right  channels.  Its  basic 
functionality  is  the  same-lt  produces  sound.  However,  FM  stereo  radios  may 
also  have  balance  controls  or  a  stereo  Indicator  light,  ztiributes  not  found  in  a 
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regular  FM  radio.  Inheritance  works  just  this  way,  taking  the  basic  func¬ 
tionality  from  one  tj'pe  of  object  and  extending  it  to  a  new  type  of  objea, 
adding  new  attributes  to  the  new  type  L'  necessary\ 

Object-oriented  terminology  states  that  a  particular  object  is  an  instance 
of  a  type  of  object,  or  class,  A  class  consists  of  all  the  types  derived  from  it, 
including  itself.  The  derived  classes  are  often  called  subclasses  or  children  of 
the  base  or  parent  class,  and  together  they  form  a  derivation  tree.  F.M  stereo 
radios  are  therefore  subclasses  derived  from  FM  radios,  which  could  in  turn  be 
a  child  of  a  generic  radio  class.  Often,  as  in  this  example,  a  derivation  tree’s 
root  class  is  abstract,  merely  factoring  out  functionality  common  in  all  of  its 
subclasses,  and  instances  of  the  abstraa  base  class  cannot  exist.  In  this  exam¬ 
ple,  the  abstract  radio  class  has  power  switches,  tuning  controls,  and  volume 
controls,  but  creating  an  Instance  of  the  radio  class  docs  net  make  sense  unless 
it  also  receives  some  band  of  frequencies,  such  as  FM,  AM,  or  short  wave.  An 
Instance  of  the  abstract  radio  class,  therefore,  must  belong  to  one  of  its  con¬ 
crete  subclasses. 

Inheritance  is  very  important  in  improving  the  maintainability  of  a 
system.  It  makes  the  task  of  extending  a  module’s  behavior  independent  of  the 
module  itself.  In  other  words,  the  new  funaionallty  can  be  added  in  a  new 
module  without  making  any  changes  to  the  original.  This  concept  is  helpful 
for  three  main  reasons.  Whenever  code  is  changed,  the  possibility  of  unin¬ 
tentionally  introducing  errors  always  exists,  and  reliability  may  therefore 
suffer.  Second,  if  a  piece  of  code  does  not  change,  it  does  not  have  to  be  tested 
again.  When  inheriting  code,  the  programmer  only  has  to  lest  the  extensions 
in  the  new  module,  saving  time,  effort,  and  cost.  The  final  reason  for  avoiding 
working  in  the  original  module  lies  with  compilation  dependencies.  If  a  mod* 
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ule  is  recompiled,  some  language  systems  require  that  all  other  dependent 
modules  also  be  recompiled  to  incorporate  any  possible  changes.  This  extra 
step  is  necessary  regardless  of  whether  or  not  the  dependent  module  actually 
used  the  new  capabilities.  Obviously  this  task  can  slow  dovm.  or  even  retard, 
development,  and  is  an  annoying  hindrance  to  a  project's  productivity.  The 
object-oriented  feature  of  inheritance  is  therefore  a  welcome  enhancement 
for  any  software  maintainer,  saving  her  from  num.erous  unnecessary  annoy¬ 
ances  [And93]. 

Just  as  the  feature  of  encapsulation  adds  to  abstraction,  the  final  major 


feature,  polymorphism,  adds  to  inheritance.  Returning  to  the  earlier  example, 
all  radios  share  a  basic  operation-they  produce  sound.  Analyzing  the  radio 
class,  radio  users  are  always  given  a  method  for  turning  a  radio’s  power  on  and 
off  to  produce  this  sound,  whether  they  have  an  A>!,  FM,  or  short  wave  radio. 
The  switches  to  do  this  operation  may  differ  depending  on  the  subclass  of  ra¬ 
dio,  and  the  inner  workings  of  the  radio’s  power  source  may  vary,  but  power 
switches  are  common  throughout  the  entire  class.  This  commonality  is  poly^ 
morphism,  the  indualve  idea  that  although  an  operation  is  invoked  similarly 
for  different  subclasses,  the  operation  may  behave  differently  for  each  class. 
Technically,  the  system  makes  a  dlspstchin^  operation,  determining  how  to 
perform  the  operation  depending  on  the  particular  subclass  upon  which  the 
operation  is  called.  If  the  system  cannot  determine  the  subclass  with  which  it 
is  dealing  until  run-time,  the  dispatch  is  performed  dynamically. 

Polymorphism  helps  us  achieve  the  goal  of  understandabllity  in  the 
same  way  function  overloading  does,  because  similar  operations  are  given 
similar  understandable  names.  If  the  main  radio  operation  is  ’■Power_On,"  this 
name  is  used  throughout  the  derivation  tree  no  matter  how  the  operation  is 
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performed.  This  convention  has  a  positive  effect  on  maintainability  for  mod¬ 
ules  that  call  a  dispatching  operation.  If  a  new  .subclass  is  added  to  a  derivation 
tree,  absolutely  no  change  will  have  lo  be  made  to  the  existing  call.  If  the  call 
is  made  with  an  object  of  The  new  h  will  still  dispatch  accordingly. 

A  general  trend  is  very  noticeable  in  the  discussion  of  object-oriented 
features.  Programmers  continually  mention  using  other  programmers'  ob¬ 
jects.  The  objects  can  call  each  other  easily  due  to  well-defined  abstractions 
and  not  worry  about  the  encapsulated  details.  They  can  design  by  inheriting 
from  and  extending  another  programmer's  design,  allowing  calls  to  be  made  to 
either  design  in  the  same  manner  with  pol>  'morphism*  This  idea  of  reLise  is 
central  to  object-oriented  programming  and  is  its  "most  tangible  advantage" 
(Ban92].  Once  an  object  and  its  operations  are  defined,  it  can  be  shared  among 
different  developers  in  one  project,  or  even  across  different  projects  altO” 
gether.  There  Is  no  need  to  try  to  modify  an  object  if  it  already  works.  If  more 
capabilities  are  needed,  simply  inherit  from  the  established  to  create  the  new. 

Reuse  is  not  a  new  idea,  but  object-oriented  programming  languages 
can  realize  its  benefits  without  the  recompilation  necessary  in  more  tradi¬ 
tional  languages.  This  feature  cuts  down  tremendously  on  production  time  and 
translates  directly  into  development  and  maintenance  savings.  Dr.  Edmond 
Schonberg  of  New  York  University  has  said  about  object-oriented  program¬ 
ming,  "the  gain  is  in  the  amount  of  code  that  one  does  not  have  to  write" 
ISch92].  This  concept  alone  is  perhaps  the  most  compelling  reason  to  readily 
accept  the  object-oriented  paradigm.  Combined  with  the  more  intuitive 
methodology  for  breaking  down  a  problem  and  the  improvements  brought  to 
the  software  engineering  goals  of  maintainability,  understandabllity,  relia- 
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billty,  and  efficiency,  it  is  clear  why  object-oriented  methods  are  revolutioniz¬ 
ing  the  software  industiy’* 

Discussion  now  turns  to  the  two  programming  languages  that  are  used 
in  this  thesis  effort  to  realize  the  objea-oriented  paradigm,  C-s-t-  and  Ada  9X. 

2.1.1  Object-Orleiived  Programming  In  C++ 


The  C+-  language  serv'es  as  an  extension  to  the  C  language,  and  both  arc  cur 
rently  used  widely  throughout  industr>’.  C  is  notorious  for  allotving  program¬ 
mers  to  produce  unstructured  code,  and  C  by  Itself  lends  little  support  for  any 
of  the  design  principles  associated  w'th  object-oriented  programming.  This 
section  addresses  the  features  of  C —  that  support  the  object-oriented 
paradigm,  giving  structure  to  the  C  language  family  [Str91,  Poh93]. 

The  class  typing  con.struct  in  C—  directly  maps  to  the  notions  of  ab¬ 
straction  and  class  in  object-oriented  terms.  A  C-+  class  defines  a  type  that  can 
be  used  by  client  programmers.  Its  definition  includes  any  attributes,  or 
members,  as  well  as  any  operations,  or  member  functions,  that  might  act  on  an 
instance  of  the  class.  The  term  member  Is  used  In  both  these  cases  to  indicate 


that  both  the  attributes  and  operations  are  declared  within  the  scope  of  the 
class  (Kcr7S,120].  Instances  of  the  class  are  achieved  through  variable  decla¬ 
rations  in  a  client  program,  and  cj'eatioii  a.nd  deletion  of  these  objects  can  be 
controlled  by  the  class  designer  through  the  use  of  automatic  constructors  and 
destructors.  The  separation  of  specification  and  implementation  that  consti¬ 
tute  abstraction  is  accomplished  in  C++  th.^'cngh  the  use  of  header  and  source 
files,  which  respectively  contain  the  two  views  of  an  objea.  The  header  file  in 
Figure  1  defines  the  interface  for  an  FM  radio. 
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The  source  file  for  the  FM_Radio  class,  shown  in  Figure  2,  defines  how 
the  member  functions  achieve  their  effects.  These  implementations  can  only 


be  accessed  by  clients  through  the  interface  defined  in  the  header  file.  The 
notation  gains  access  into  the  scope  of  the  class  preceding  the  symbol,  and 
is  necessary  because  many  classes  can  have  member  functions  with  the  same 
name  [Str91.145].  It  is  also  vital  because  C++  does  not  define  rules  for  locating 
the  definitions  of  the  member  funaions  in  any  specific  source  file=  Note  how- 
no  part  of  the  language  determines  the  beginning  or  end  of  the  header  file--it 
is,  by  convention,  a  simple  list  of  the  definitions  of  the  member  functions  but 
it  could  easily  contain  other  entities. 


//  file  ;n\_radio.h 
class  FM_F.adio 

public:  //  Grants  client  prograrjr.ers  access  to  what  fcllcws 

rK_Radic  //  Co.nstructcr  has  sairie  naite  as  class 

“?>'_Sadio  //  Ciestrjctcr ’ s  name  is  siir.ilar,  but  v.-ith  tilde 

//  Member  functions: 

//  Syntax —  return-type  name  (parameter-type  paramster-naTis!  ; 

void  Po\-.’er_On  ():  //  Void  functions  return  no  values 

void  ?o-*'6r_0ff  O:  //  Hrpty  parameter  lists  must  be  explicit 

void  Voluine_Up  ( ;■  ; 
void  Volur.e_Down  {); 

void  Tun ing_0p  (); 
void  Tjni.ng_Dcwn  (); 

float  Station  (); 


//  Regular  .members,  storing  state  of  class: 
iat  power;  //  &  is  cff 

int  current_voluir.e; 
float  current_szaticn; 

//  Semi-cclcn  completes  class  declaration 

Figure  1.  FM_Radio  Class  Header  File 
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♦rincluda  ■fr._r£dio.h“ 

FK  Radies :?K_Radio 

( 

pov.'sr  =  0; 

currer.t_vol‘Jir,e  =  0; 
currer.t_staticn  =  97.7; 

//  He  seni-rolor.  here 

Other  member  functions  omitted 

FM_P  a  d  i  o :  :  ?owe  r_Or.  ( ! 

{ 

power  =  1; 

) 


/'/'  and  sc  cn... 


figure  2.  FM.Radio  Class  Source  File 


Instances  of  a  C-^+  class  each  get  their  own  copies  of  all  Its  members. 
When  a  member  function  is  called  in  a  client  program,  the  instance  name  is 
part  of  the  call,  and  the  member  data  upon  which  the  funaion  operates  Is 
passed  implicitly.  Figure  3  shows  a  main  C++  function  that  uses  the  FM_Radio: 

Just  as  the  FM_Radio  header  file  above  declares  a  part  of  the  flle  to  be 
public,  it  can  declare  a  part  to  be  pr/vate.  This  feature  brings  encapsulation  to 


//  file  main.ee 


(Unelude  •fm_radio.h*  //  7c  access  class  header  file 


int  ir«in  {) 

I 

i 

FM_Radio 


*Kl’_Radic; 


/  : 


*  *  •— 


©  •  ^  •s 


My_Radic  =  naw  ?K_Radio  ();  H  Allocates  space  &  calls  constructor 


I-!i'_Radio->Pov.-er_On  ();  f!  Turns  or.  Mi'.Kadio  instance 

My_Radio->Volume_’Op  0  ;  //  Turns  up  l-li'.Radio  instance 


Figure  3.  Main  Using  FM.Radlo  Class 


C-+,  hiding  whatever  is  declared  in  the  private  part  from  clients  of  the  class, 
and  only  allowing  access  to  member  functions.  In  fact,  private  is  the  default, 


and  all  members  will  be  encapsulated  unless  explicitly  listed  otliePvVise.  Nop 
mally,  a  class  encapsulates  its  regular  members  in  the  private  part,  while 
keeping  its  member  functions  available  in  the  public  part.  The  definition  of 
member  functions  in  a  separate  source  file  also  contributes  to  the  encapsula¬ 
tion  of  C++. 

Any  C-r+  class  can  form  the  root  of  a  derivation  tree,  and  this  feature 
brings  inheritance  into  the  language.  Another  class  can  simply  declare  that  it 
is  a  child  of  FM.Radio,  and  it  gets  a  local  copy  of  all  the  members  of  the  parent 
class.  The  derived  class  does  not  gain  any  special  privileges,  however,  and  any 
members  of  the  base  class  declared  private  are  inaccessible  to  the  child.  If  this 
effect  is  not  desired,  the  parent  can  have  a  part  similar  to  its  public  and  pn* 
vate  parts,  called  protected,  and  any  members  declared  in  this  part  are  visible 
throughout  its  descendant  subclasses.  A  child  class  can  add  member  data  ele¬ 
ments  to  those  inherited  from  its  parent  by  simply  declaring  more  of  its  own, 
in  whichever  of  Us  own  parts  it  prefers. 

The  subclass  cannot,  however,  customize  its  parent's  member  functions 
unless  the  parent  explicitly  grants  permission  for  this  polymorphism  to  occur. 
A  class  can  declare  any  of  its  member  functions  to  be  virtual,  allowing  that 
function  to  be  overridden  or  redefined  by  its  subclasses.  Additionally,  a  class 
can  make  itself  abstract  by  Indicating  that  one  or  more  of  its  virtual  functions 
is  pure.  Pure  virtual  functions  cannot  have  definitions  in  the  cla.ss  in  which 
they  are  members,  and  no  instances  of  a  class  with  pure  virtual  functions  can 
be  created.  Any  descendant  of  an  abstract  class  must  override  the  abstract 


//  file  radio. h 


claaa  Radio 
public: 

Radio  {);  //  Inlined  null  function  acts  as  destructor 

-Radio  //  Sir.ple  furjctions  can  likewise  be  inlined 

virtual  void  Power_On  { } ; 
virtual  void  ?cwcr_Off  I;; 

virtual  void  Volurr.e_yp  (); 
virtual  void  Voluir,e_!iovn  (); 

virtual  void  Tuning_t;p  ()  e  0;  //  "c  0"  indicates  pure  function 

virtual  void  Tuning_I>ov.’n  ()  =0;  //  Frequency  band  is  unknown 

virtual  int  Station  ()  =  C; 
virtual  float  Station  {)  =  C; 

protect ad: 

int  power;  /.'  0  is  off 

int  current_volime; 


); 


Figure  4.  Abstract  Radio  Class  Header 


functions,  unless  It  too  is  intended  to  be  abstract.  Figure  4  shows  the  abstract 
Radio  class,  and  Figure  5  demonstrates  how  the  FM_Radio  is  derived  from  it. 

The  main  program  can  now  declare  instances  of  any  class  derived  fro.m 
Radio,  and  expea  that  if  a  Tuning  or  Station  member  funaion  is  called,  the  ap¬ 
propriate  routine  will  be  executed  depending  on  the  subclass  of  the  instance. 
Figure  6  shows  a  funaion  which  demonstrates  this  polymorphism. 

In  this  example,  the  parameter  passed  to  Turn_Off_Radio  is  a  pointer  to 
any  subclass  of  the  abstract  Radio  class.  When  making  the  call  to  Power_Off, 
the  run-time  system  will  determine  the  actual  subclass  of  the  parameter  and 
dispatch  the  call  to  the  Power_Off  function  for  that  subclass,  be  it  an  FM.Radio, 
an  AM_Radio,  a  Short_Wave_Radio,  or  a  Banana_Radio,  whatever  that  may  be. 
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This  section  has  provided  a  brief  overview  of  the  C+-  language's  support 


//  file  fn)_radio.h 
^include  "radio. h" 

class  FM_Radio  :  public  Radio  //  Derived  frorr.  Radio 
{ 

public : 

n'_i^a<aic  v);  //  override  ccnszruotcr 

//  DeswructcTf  Fov*6r,  Vol\2!^6  functions  iXc  iniisritsd  *5  is 

virtual  void  Tunir.g_'Jp  {);  //  Redefine  pure  functions,  and  make 

virtual  void  TJnir.s_Dov.T.  ();  //  virtual  to  allov;  over- iding 

virtual  int  Station  { ) : 
virtual  float  Station  {); 

protaetad; 

float  current_staticn;  Add  new  frequency  band 


): 


Figure  S,  FM_Radio  Subclass  Header 


for  the  object-oriented  programming  paradigm.  More  in  depth  treatm.ent  of 
the  subject  is  available  from  many  sources  [Str91,  Poh93].  Discussion  now 
continues  with  a  similar  implementation  of  the  radio  hierarchy  in  Ada  9X. 

2.1.2  Object-Oriented  Programming  in  Ada  9X 


The  Ada  programming  language  became  an  ANSI  standard  in  1983,  with  the 
intent  that  It  would  be  updated  periodically  as  programming  methodologies 
evolved.  Ada  9X  is  the  first  of  these  updates,  supplementing  the  original  lan- 

void  Turr._0£f_R£dio  -Radio  *My_R&dic; 

{ 

Wy_Radio->?cwer  Off  //  Dj'njjr.ic  dispacchir.G  call 

) 

Figure  6.  Dispatching  Radio  Function 


23 


guage  with  many  new  features  deemed  necessar>'  by  its  users.  Ada  9X  was  ap¬ 
proved  by  the  International  Standards  Organization  in  November  1994,  and 
will  be  officially  dated  according  to  the  printing  date  of  the  new  Ada  Language 
Reference  Manual.  Upward  compatibility  has  been  a  pnmar>'  goal  of  the  re¬ 
vision  process,  and  because  Ada  9X  fully  embraces  Ada  83,  this  objective  has 
been  successfully  achieved. 

Unlike  the  C  basis  of  C-+,  the  Ada  83  basis  for  Ada  9X  already  provides  a 
sound  basis  for  objea-oriented  principles,  fully  supporting  both  abstraction 
and  encapsulation,  ft  also  contains  a  limited  form  of  inheritance,  but  does  not 
readily  allow  polymorphism.  This  section  look'  at  the  Wa  features  that  address 
the  four  objea-oriented  principles.  A  trait  common  solely  to  one  of  the  Ada 
versions  is  clearly  indicated,  while  mention  of  an  "Ada"  feature  indicates  a 
feature  common  In  both  versions. 

Because  the  Ada  language  was  originally  Intended  to  be  used  on  large 
software  development  projeas.  Its  designers  decided  to  provide  extensive  ca¬ 
pabilities  for  abstraa  data  tj'pes.  Ada  realizes  this  well-proven  programming 
concept  by  an  Idiom  using  both  Us  private  type  and  package  features.  An  Ada 
package  can  serve  as  a  container  for  many  programming  entities,  but  it  is  also 
a  tool  for  abstraction.  Just  like  the  C+4  class,  an  Ada  package  physically  sepa¬ 
rates  its  interface  from  its  implementation,  and  these  pans  are  respectively 
called  the  specification  and  body  of  the  package.  Ada  mixes  Its  rich  typing 
facilities  with  packaging  in  the  form  of  private  t>'pes,  which  split  a  package’s 
specification  into  public  and  private  parts.  The  private  lypt  and  any  opera¬ 
tions  that  manipulate  its  values  are  declared  in  the  public  part,  so  that  client 
programmers  can  access  them.  The  components  that  the  private  type  com¬ 
prises  are  then  defined  In  the  private  part  of  the  package  specification,  and 
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are  encapsulated  so  chat  the  client  programmer  cannot  access  them.  The  body 
of  the  package,  which  defines  the  implementation  of  the  operations  that  ma¬ 
nipulate  values  of  the  private  type,  has  full  access  to  the  specificatioii  s  pri" 
vate  part,  but  is  also  hidden  from  any  client  programmers.  Ada  packages  that 
export  private  types  are  sometimes  called  c/ass  packages,  since  the  abstract 
data  type  corresponds  to  a  class  in  the  object-oriented  paradigm  [Cer93].  In 
fact,  experts  often  call  Ada  83  an  object-based  language  because  of  its  abstract 
data  typing  facilities  lBoo94,  Taf92a]. 

Returning  to  the  example  of  the  FM  radio,  Ada  syntax  corresponding  to 
the  C+-  code  for  the  FM.Radlo  class  appears  in  Figure  7. 

The  most  notable  semantic  difference  between  the  C++  code  and  the  Ada 
code  is  the  use  of  parameters  in  the  operations  of  the  FM_Radio  class.  Ada  re- 

•y  rAfieormonr/i  rvf  ire  ciir>T>nrr  fnr  rrvnoirrA?-ir\/  Ra* 

quires  tnese  pAraiucvers  as  a 

cause  an  Ada  procedure  or  function  must  be  able  to  execute  flawlessly  when 
many  copies  of  it  are  running  concurrently,  each  copy  must  get  its  own  copy 
of  the  data  upon  which  it  is  operating. 

The  result  for  the  client  programmer  is  not  very  dire,  as  the  names  used 
in  the  call  simply  appear  in  a  different  order.  The  main  difference  in  the 
client  is  the  reference  that  is  made  to  the  package  tvhere  the  type  and  its  op¬ 
erations  are  defined.  Ada  uses  this  explicit  reference  to  Increase  maintain¬ 
ability  on  large  programs,  where  tracing  a  declaration  can  be  cumbersome. 
This  explicit  referencing  can  be  circumvented  if  the  programmer  so  desires, 
but  this  praaice  is  discouraged  and  is  not  shown  in  Figure  8. 
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--  fils  firi_radic .ads 

—  Naming  conventions  for  objects  taken  from  [CerSJl 

—  See  appropriate  section  belov.*  for  more  information. 

package  ia 

type  Object  is  private;  —  Private  type  declaration 

--  Operation  declarations 
--  Syntax--  procedure  [functior/  name 

'(Parameter -name  ;  parameter-modes  parameter -type) 
('return  return-type]; 

procedure  Fcwer_Cn  (Instance  :  in  out  Object); 
procedure  Power_Off  (Instance  :  in  out  Object}; 

procedure  Vol'jmie_t;p  (Instance  :  in  out  O'oject); 

procedure  Volume_r)ov.Ti  (Instance  ;  in  out  Obiect); 

procedure  'rur.ing_Up  (Instance  :  in  out  Object); 

procedure  ?ur.ir.g_DovTi  (Instance  ;  in  out  Object); 

function  Station  {Instance  :  in  Object)  return  Tloi.; 

private 

--  Encapsulated  typos  needed  fcr  full  private  type 
type  Sv.'itc'n  la  (Off,  On)  ; 
subtype  Preg-uency  ia  Float  r^mga  67.7..1C7.9; 
aubtypa  Vol-ums  ia  Natural  ranga  C.  .10; 

--  Full  private  type  definition 
type  Object  ia 

raeord  —  default  initial  values  provided  for  components 

Power  :  Switch  ;=  Off; 

Curr€nt_Steticn  :  Frequency  :=  Frequency 'First; 

Curre.nt_Veltimie  :  Volume  :=  D; 

and  record; 

end  FK_Sadio; 


--  file  fm_radio.adb 

package  body  FK_F:adio  is  —  Body  tells  ccm.piler  what  it  is 

procedure  Fower_On  (Instance  :  in  out  C'cject;  ia 
begin 

Instance. Fewer  ;=  On; 
and  Fower_0.n; 

--  And  so  on... 

and  FM^Kadio; 

Figure  7.  FM_Radio  Gass  Package 
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£il»  listener .adb 

with  FM_Radio:  —  Tc  access  public  package  ccntc-nts 

procadura  Listener  i» 

M-j-.Radio  :  FM_ Radio. Object;  --  Declares  instance  of  FM_Radic 

begin 

FK_Radic.Fcwer_On  ;My_Radio; ; 

FI^_Radic  .Vclume_Up  ;My_Radio} ; 

and  Listener; 

Figure  8.  FM  Radio  Listener  Procedure 

Ada  83  permits  inheritance  of  an  object's  attributes,  inheritance  of  an 
object's  operations,  and  extension  of  an  object's  operations  through  its  derived 
types.  A  type  declared  in  a  package  Specification  is  automatically  Mer/yab/e,  as 
are  any  subprograms  in  the  public  part  of  the  package  specification  that  take 
a  parameter  of  the  ty'pe  in  question.  These  subprograms  are  called  the  tyTDe’s 
primitive  operations.  A  client  program  unit  can  derive  a  new  type  from  the 
original,  and  the  child  inherits  the  attributes  and  operations  of  the  parent. 
The  child  may  override  any  of  the  inherited  subprograms  as  necessarv',  and 
any  subprograms  it  declares  that  take  a  parameter  of  the  derived  ty'pe  are 
further  derivable  in  other  program  units. 

Ada's  derived  types  do  not,  however,  allow  extension  of  an  object's  at¬ 
tributes,  a  concept  vital  to  object-oriented  programming.  Ada  introduces  a 
new  kind  of  record  t>'pe  to  correspond  to  a  class,  called  the  tagged  type,  that 
allows  new  record  components  to  be  added  to  any  type  derived  from  it.  Tagged 
types  therefore  provide  full  support  for  inheritance.  The  new  components 
that  correspond  to  the  attributes  of  the  subclass  may  be  specified  in  the  public 
part,  but  a  design  fully  adhering  to  the  idea  of  encapsulation  declares  the  new 
attributes  with  a  private  extension,  defined  in  the  package’s  private  part. 
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Tagged  types  may  also  be  abstract,  and  may  declare  abstract  operations  that 
must  be  overridden  in  child  classes.  Finally,  a  lagged  r-  pe  may  be  controlled, 
providing  a  default  constructor  and  destruaor,  if  it  ii  derived  from  a  prede¬ 
fined  abstract  tagged  type  called  Ada.Finalization.Conirolled;  .Ada  9X'5  con¬ 
trolled  types  also  allow  value  adjusting,  so  that  assignment  between  different 
instances  of  a  class  can  also  be  controlled  by  the  programmer.  If  assignment 
is  not  desired  between  instances  of  a  class,  the  class  can  be  derived  from 
Ada.Finalizaiion.Limited_Controlled.  These  limited  controlled  types  only  in¬ 
herit  a  constructor  and  destructor.  The  package  specification  in  Figure  9 
shows  the  Ada  9X  version  of  the  controlled,  abstract  Radio  class. 

Just  as  in  the  C+-i-  implementation  of  classes,  Ada  9X  does  not  allow  a  child 
class  default  access  to  its  parent’s  private  part.  Unlike  C++,  however,  Ada  9X 
does  not  grant  the  parent  class  the  ability  to  change  this  sometimes  bother¬ 
some  feature.  In  Ada  9X,  the  derived  type  takes  control  by  exploiting  the  new 
feature  of  hierarchical  library  units.  The  new  package  declares  Itself  to  be 
part  of  another  package,  so  that  it  is  logically  nested  inside  its  owner,  even 
though  it  is  physically  separated.  Because  Ada  9X’s  new  type  of  package  is  used 
in  combination  with  inheritance,  it  is  often  referred  to  as  a  child  library  unit, 
or  simply  a  child  package.  In  visibility’  terms,  the  child  package  does  not  need 
to  access  its  parent  package  using  an  explicit  w/rh  clause,-  because  the  com¬ 
piler  recognizes  the  child's  intent  to  be  part  of  its  parent.  The  public  part  of 
the  child  is  logically  located  at  the  end  of  the  parent's  public  part,  and  the  pri¬ 
vate  part  of  the  child  is  logically  located  at  the  end  of  the  parent's  private  part, 
so  that  the  child  has  access  to  the  entire  parent.  The  package  specification  for 
the  FM  radio  child  class  package  follows  in  Figure  10. 
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£il«  radio. e.ds 


with  Ada.Finalizazicn; 


Tc  provicife  ecrizrclied  capalMlities 


package  Radio  la 

—  Allov.’  visibility  of  attribute  types: 
type  Sv.’itch  ia  <Off,  On); 

Bubtype  Voluas  iB  Natural  range  C..lCr 

—  Make  subclass  of  base  for  controlled  types: 

type  Object  Is  abstract  new  Ada. Finalization. Controlled  with 
private ; 


Controlled  operations: 


procBdurB 

Initialize 

{Instance  : 

in 

out 

Object! ; 

procadur* 

Adjust 

{Instance  : 

in 

out 

Object; ; 

procBdura 

Finalize 

'Instance  : 

in 

out 

Ob j  ect ! ; 

procBdura 

Fower_On 

(Instance  : 

in 

out 

Ob j  ect ; ; 

procedur* 

Power_Cf f 

{Instance  : 

in 

out 

Cbjec.:)  ; 

procttdura 

Vcluirie_Up 

(Instance  : 

in 

out 

Object) ; 

procadurB 

Voluina_Dcwn 

(Instance  : 

in 

out 

Cbject) ; 

proesdurB 

Tun ing_Up 

(Instance  : 

in 

out 

Object) 

iB 

abstract ; 

pre  cbdur# 

Tuning_Dov.'n 

(Instance  : 

in 

out 

Object) 

iB 

abstract ; 

function  Station  (Instance  ;  Object! 

return  Natur 

al 

iB 

abstract ; 

function  Station  (Ins 

tance  :  Object) 

return  Float 

ie 

abstract ; 

private 

type  Object  Is  abstract  new  Ada. Finalization .Controlled  with 
record 

Fewer  :  Switch  ;=  Off; 

Current_Vclurr.e  :  VeluiRe  ;=  0; 
end  record 

end  Radio; 

Figure  9.  Controlled,  Abstract  Radio  Class  Package  Specification 


Just  as  lagged  types  bring  the  object-oriented  principle  of  inheritance 
to  Ada  9X,  they  also  bring  polymotphism  to  the  language.  The  name  tsgged,  in 
fact,  refers  to  the  polymorphic  qualities  of  lagged  types,  as  the  system  main¬ 
tains  a  tag  to  keep  track  of  an  instance’s  subclass,  so  that  it  can  dispatch  to  the 
proper  primitive  operation.  Because  each  tagged  type  forms  the  root  of  a  class 
derivation  tree,  Ada  9X  provides  a  new  language  type  attribute  for  tagged  tvp.®s 
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--  file  radio-fn.ads 
package  R&dic.FM  la 

Bubtype  Frequency''  is  Float  range  S7 .7 .  .107  .?>; 

type  Object  ia  new  Sadie. Object  with  private; 

procedure  I.nitialise  (Instance  :  in  out  Object); 

--  other  Controlled,  Pov.-er,  and  Volume  operations  inherited 

--  Abstract  operations  must  be  overridden; 
procedure  Tur.ir.c_Up  {Instance  :  in  out  Object); 
procedure  Tuninc_Dowr.  {Instance  :  in  out  Object); 

function  Station  {Instance  :  Object)  return  Natural; 
function  Station  {Instance  :  Object)  return  Float; 

private 

type  Object  is  nsw  Radio. Object  with  record 

Current_Station  :  Frequenci'  :=  Frequency ‘ first ; 

—  Power,  Currer.t_Volume  inherited 

end  record; 

and  Radio. FM; 

Figure  10.  ?M  Radio  Subc)as5  Child  Package  SpecificaUon 


called  T'Oass.  This  attribute  refers  to  any  subclass  in  the  hierarchy  started  at 
type  T,  and  allows  the  declaration  of  unconstrained  objects  that  can  take  the 
form  of  any  t>’pe  derived  from  T.  These  objects  are  accordingly  called  c/ass- 
wde  objects,  and  can  be  declared  wherever  an  objea  declaration  is  appropri¬ 
ate.  Figure  1 1  shows  a  modification  to  the  Listener  procedure  previously  seen 
in  Figure  8.  Listener  Is  now  a  classwide  operation  because  it  takes  a  classwide 
object  as  a  parameter  to  exploit  the  d>T.aniic  dispatching  available  in  Ada  9X. 

Both  of  the  procedure  calls  above  perform  dynamic  dispatching.  The 
procedure  corresponding  to  the  Instance's  tag  will  be  called  by  the  system,  and 
this  procedure  may  not  necessarily  be  the  one  defined  in  Radio.  Classwide  op¬ 
erations  normally  call  the  operations  of  the  root  type  for  understandability  as 
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file  listener. adb 


with  Radic;  —  Tc  access  roct  cf  hierarchy 

procedure  Listener  (Instance  :  in  out  Radic .Cb;ect ’Class)  is 

begin 

Radio .  Pov.’er_On  ( Instance ) ; 

Radio. Volunie_wp  (Instance); 

end  Listener; 

Figure  11.  Classvkide  Radio  Listener  Procedure 


shown  here,  but  run-time  polymorphism  allows  any  primitive  operation  in 
the  classwide  object's  hierarchy  to  be  used  [Taf92aj. 

While  classwide  objects  are  quite  useful,  in  object-oriented  program¬ 
ming  it  is  often  more  practical  to  deal  with  pointers  to  objeas.  Ada  9X  provides 
classwide  access  types  to  implement  this  functionality,  and  these  types  are 
normally  Included  in  a  class  package  to  provide  additional  capability.  A 
classwde  access  t>'pe  declaration  appears: 


type  Reference  la  acceea  all  Object 'Class 


Assuming  this  line  exists  in  the  Radio  class  package,  the  Listener  procedure 
can  be  changed  to  handle  pointers,  with  an  adjustme.nl  made  in  the  actual  pa¬ 
rameter  passed  to  the  calls  accounting  for  the  pointer  dereference.  Figure  12 
shows  the  new  version  of  Listener.  Seeing  pointers  used  in  this  fashion,  and 
realizing  that  the  .all  dereference  is  not  aesthetically  pleasing,  it  wo’uid  seem 
that  the  next  logical  step  would  be  to  change  the  parameter  types  of  the  deriv¬ 
able  operations  to  use  classwide  access  types  instead  of  tagged  types.  This  move 
would  be  quite  erroneous,  however,  because  It  Is  the  tagged  Ty-pe  parameter  it¬ 
self  that  makes  the  operations  derivable  and  allows  dispatching  to  occur. 
Changing  the  parameter  type  of  the  primitive  operations  to  a  classwide  access 
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£ii«  listener. adb 
with  ?iedic; 

procedure  listener  ; Instance  ;  in  out  Radio .Soference)  ia 
begin 

Radio. Pov,'cr_C.T  (Instance. all) ; 

R6d:o.Voluni6_L'p  (Instance .all)  ; 

end  listener; 


Figure  12.  Classwide  Radio  Listener  Protedur-e  with  Ai 


/•/•oet  T\rnf>t 


type  is  unnecessary,  as  the  Intent  of  the  change  Is  already  provided  with  the 
simple  tagged  type.  The  somewhat  ugly  result  of  this  rule  Is  the  necessity  to 
keep  the  .all. 

This  section  has  provided  a  brief  overview  of  the  Ada  9X’s  support  for 
the  object-oriented  programming  paradigm.  More  in  depth  treatment  of  the 
subject  Is  available  from  many  sources  (Bal93,  Bar93,  Bar94,  Cer93,  Coh93, 
Kam93  Kem94,  Rat94].  Discussion  now  turns  to  one  method  for  analyr.ing  a 
problem  In  an  object-oriented  fashion,  Independent  of  programming  lan¬ 
guage. 


2.1,3  The  Rumbaugh  Objea  Modeling  Technique 

Dr.  James  Rumbaugh  and  his  colleagues  at  the  General  Electric  Research  Cen¬ 
ter  have  devised  an  object-oriented  approach  to  attacking  the  analysis  and  de¬ 
sign  phases  of  the  system  life  cycle.  Thi.s  methodology  is  called  the  Object 
Modeling  Technique,  and  results  In  a  design  that  is  independent  of  both  pro¬ 
gramming  languages  and  hardware  platforms  (Rum91].  Although  the  Object 
Modeling  Technique  covers  many  aspects  of  the  analysis  and  design  phases, 
this  seaion  centers  on  the  Rumbaugh  diagrams  that  are  used  to  show  the  rela¬ 
tionships  among  the  objects  in  a  system.  Figure  13  shows  a  Rumbaugh  dia¬ 
gram  of  the  Radio  system,  in  order  to  illustrate  the  features  of  the  Object 
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Figure  13.  Rumbaugh  Objea  Mode!  Diagram  for  Radio  Hierarchy 


Modeling  Technique  that  are  necessar)'  for  this  thesis,  additional  classes  are 
shown  that  have  not  been  previously  discussed. 

Each  box  shows  a  class  within  the  hierarchy,  with  the  optional  three 
subdivisions  respectively  showing  the  name,  the  set  of  simple  attributes,  and 
the  set  of  operations  that  belong  to  the  class.  A  simple  attribute  may  denote  an 
Initial  or  default  value,  and  an  operation  may  specify  any  parameters  needed 
to  perform  Its  task.  There  is  no  specific  way  to  show  an  abstract  class,  so  this 
characteristic  may  be  written  explicitly.  In  the  figure,  the  abstract  Radio  class 
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has  two  attributes,  both  of  which  have  default  values.  The  operations  of  the 
Radio  class  are  shown  in  pairs,  and  the  abstract  operations  are  noted.  In  the 
FM_Radio  class,  only  the  new  attributes  and  the  new  or  overriding  operations 
are  indicated. 

Lines  connecting  the  classes  represent  the  relationships  that  exist  be¬ 
tween  them.  Inheritance  is  shown  with  a  triangle,  and  the  diagram  above 
therefore  demonstrates  that  the  AM_Radic.  Short_W'ave,  and  FM_Rad!o  classes 
are  all  derived  from  the  Radio  class.  Aggregation  is  a  special  relationship  in 
object-oriented  analysis  that  indicates  that  a  class  has  attributes  that  are  them¬ 
selves  classes.  These  attributes  are  separated  from  simple  value-oriented  at¬ 
tributes  because  more  Information  is  required  to  understand  their  values  and 
operations.  In  the  diagram  above,  the  Radio  class  and  all  its  descendants  are 
now  composed  of  Displa3's,  Knobs,  and  Buttons,  in  addition  to  the  simple  at* 
tributes  already  mentioned. 

VS'hile  inheritance  and  aggregation  are  common,  relationships  benveen 
classes  can  exist  that  do  not  have  special  characteristics.  A  normal  line  shows 
that  an  instance  of  a  class  on  one  end  must  coexist  with  an  instance  of  the 
other  class,  and  these  lines  are  normally  labeled  to  describe  the  relationship. 
Different  multiplicity  balls  dictate  the  number  of  instances  that  must  be  re¬ 
lated  in  the  real  system.  An  outlined  ball  indicates  an  optional  relationship, 
while  a  solid  ball  shows  that  any  number  of  instances  of  the  class  can  be  re¬ 
lated.  In  the  Radio  Object  Model,  the  Listener  class  must  use  an  FM_Radio,  al¬ 
though  the  FM_Radio  can  stand  on  its  own.  The  three  classes  that  make  the 
aggregate  for  the  Radio  also  have  multiplicity  balls.  They  indicate  that  a  Radio 
may  or  may  not  possess  a  Display,  can  have  any  number  of  Knobs,  and  can 
contain  as  many  Buttons  as  it  needs. 


34 


This  section  has  introduced  the  basics  of  the  Rumbaugh  Object  Modeling 
Technique.  More  details  can  be  found  in  the  text  that  Dr.  Rumbaugh  and  his 


colleagues  have  published  [Rum91j.  Discussion  now  addresses 
developing  Ada  9X  code  fror  Rumbaugh  Object  Models. 


2.1.4  Representing  Object  Models  In  Ada  9X  Notation 


This  section  serv'es  as  a  summary’  of  a  technique  for  Representing  Object  Mod¬ 
els  in  Ads  9X  Notation  (R0MAN-9X)  {Cer93].  It  serves  as  the  basis  for  convert¬ 
ing  Rumbaugh  diagrams  into  Ada  9X  package  specifications.  This  design 
methodology  has  already  been  used  throughout  the  discussion  above  to  imple¬ 
ment  the  radio  hierarchy,  but  is  explained  more  explicitly  here.  Some  addi¬ 
tions  to  the  technique  have  been  made,  and  they  are  included  in  the  discussion 
below. 

The  basis  of  ROMAN-9X  is  that  each  class  is  Implemented  in  its  own  class 
package,  a  module  which  wholly  and  distinctly  contains  everything  particular 
to  that  class.  To  aid  program  readability,  the  package  name  is  chosen  carefully 
to  serve  as  the  name  of  the  class.  The  class  type  represents  the  class  Itself  and 
is  called  Objett.  The  class  type  Is  Implemented  as  a  tagged  type  to  allow  inheri¬ 
tance,  and  is  usually  controlled  to  allow  for  construaors  and  destructors.  The 
Ada  type  mark  for  client  programmers  declaring  instances  of  the  class  is 
therefore  Class..Name.Objea.  This  name  reads  nicely,  and  avoids  confusion  by 
equating  the  class  name  with  the  Ada  type  itself.  To  provide  flexibility  in  us¬ 
ing  the  class,  the  class  package  provides  a  classwide  access  Dq^e  named  Refer¬ 
ence.  This  type  allows  client  programmers  to  easily  and  efficiently  use  the 
class  as  an  attribute,  and  allows  more  flexibility  in  the  exploitation  of  poly¬ 
morphism. 
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Class  operations  are  declared  as  procedures  and  functions  in  the  public 
part  of  the  class  package  specification.  Default  initialization  Is  accomplished 
either  through  explicit  initialization  in  the  record  component  declaration  or 
by  Initialize  if  a  controlled  tj'pe  is  used.  In  cases  where  parameters  must  be 
passed  to  complete  initialization,  perhaps  because  of  dynamically  determined 
data  values,  a  procedure  called  Configure  takes  in  the  necessaiy  values.  By 
convention,  the  class  object  is  the  first  parameter  to  any  operation,  and  the 
formal  parameter  is  named  Instance.  This  standard  idiom  aids  readability  and 
provides  a  similar  way  for  all  operations  to  refer  to  the  instance  of  the  class 
object  upon  which  they  are  operating. 

Class  attributes  are  encapsulated  in  the  tagged  record  in  the  private  pan 
of  the  package  specification.  The  class  declares  Get  and  Set  operations  to  ac¬ 
cess  the  class  attributes  when  necessary-,  and  the  attributes  are  never  accessed 
globally.  The  Get  operations  are  implemented  as  functions  when  possible,  and 
are  given  the  name  of  the  attribute  they  return.  If  the  Get  operations  returns 
more  than  one  value  and  must  therefore  be  a  procedure,  it  is  named 
Cet_(Attrlbute).  The  Set  operations  are  always  procedures,  and  are  named 
Set_( Attribute).  Both  the  Get  and  Set  operations  are  inlined  whenever  possi¬ 
ble.  If  the  class  Is  an  aggregate,  and  it  has  attributes  that  are  themselves 
classes,  these  attributes  are  stored  as  References,  and  the  class  package  that 
defines  the  attribute  must  be  accessed  via  a  with  clause.  Using  a  classwide  ac¬ 
cess  to  the  attribute  allows  the  attribute  to  be  passed  easily  and  efficiently  and 
avoids  the  potential  dispatching  conflict  of  having  two  distinct  tagged  types  In 
an  operation's  parameter  list.  U  also  allows  the  attribute  to  take  on  the  value 
of  any  subclasses  that  may  be  derived  from  the  class  originally  envisioned. 
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A  derivation  tree  is  rooted  at  a  class  package  using  the  hierarchical  li¬ 
brary'  units  of  Ada  9X.  The  root  of  the  tree  serves  as  the  base  class  package, 
with  each  descendant  Implemented  in  a  child  package.  A  hierarchy  with  an 
abstract  root  is  implemented  using  the  corresponding  new  Ada  9X  syntax  for 
abstract  types.  Within  the  hierarchical  packages,  the  package  name  indicates 
a  class'  position,  with  each  dot  indicating  its  depth  within  the  derivation  tree. 

Having  gone  from  the  basics  of  the  object-oriented  methodology  to  a 
technique  for  creating  object-oriented  code,  discussion  now  turns  to  more 
general  st>’les  for  designing  software  architectures. 

2.2  Software  Architectures 


Da\1d  Garlan  and  Mar3'  Shaw  of  Carnegie  Mellon  University’s  School  of  Com¬ 
puter  Science  teach  a  course  on  Software  System  Architectures,  and  have  re¬ 
cently  summarized  their  knowledge  base  [Garl95).  This  section  discusses  "the 
current  state  of  the  discipline,"  by  explaining  Garlan  and  Shaw’s  definition  of 
a  sofnvare  architecture  and  describing  numerous  architeaural  styles. 

A  software  architecture  defines  the  style  used  to  organize  a  software 
system.  This  style  helps  to  structure  the  flow  of  control  throughout  the  sys¬ 
tem,  and  decides  which  portions  of  the  system  handle  which  of  the  required 
tasks  and  computations.  An  archlieaure  also  establishes  standard  techniques 


used  for  communicating  and  accessing  data  in  the  system  lGarl93,l].  By  creat¬ 
ing  a  software  architecture,  a  system  becomes  easier  to  grasp  for  anyone  trj’- 
ing  to  analyze  it,  design  it,  Implement  it,  or  maintain  it.  The  architecture  de¬ 
fines  a  prescribed  structure  that  the  system  follows,  and  comprehending  this 
base  structure  eases  understanding  throughout  the  entire  system  .  While  it 
may  not  seem  that  a  maintenance  programmer  has  this  need,  realizing  the 
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scope  of  the  changes  she  Is  making  within  the  system  can  allow  her  to  ac¬ 
complish  her  task  much  more  efficiently,  responsibly,  and  safely. 

Technically,  Garlan  and  Shaw  state  that  a!!  architectures  are  broken 
into  components,  so  that  the  pieces  of  the  system  are  more  understandable  and 
manageable.  Communication  methods  between  these  components  occurs  ac¬ 
cording  to  the  architecture's  system  of  connectors.  Finally,  the  behavior  of 
the  system  must  adhere  to  certain  constraints,  which  -set  rules  for  combining 
the  components  and  connectors.  The  constraints  help  the  system  to  be  more 
uniform,  which  also  makes  it  more  understandable  by  decreasing  its  complex¬ 
ity  lGarl93,4-5].  In  order  to  completely  understand  different  methods  for 
defining  components,  connectors,  and  constraints,  Garlan  and  Shaw  give 
many  examples  of  architectural  styles.  This  section  analyzes  those  that  are 
pertinent  to  this  research  effort,  by  first  explaining  them  and  then  discu.ssing 
their  advantages  and  disadvantages. 

The  pipe  and  filter  architecture  Is  familiar  to  users  of  the  UNIX  operat¬ 
ing  system  because  it  works  ver>’  similar  to  the  piping  com.m.ands  found  there. 
A  pipe  model  indicates  that  data  is  brought  into  the  system,  manipulated  or 
filtered  by  one  component,  passed  to  another  component,  filtered  again,  passed 
in  a  different  form  further  down  the  pipe  to  the  next  component,  passed 
through  another  filter,  and  so  on.  until  the  final  produa  Is  finally  achieved. 
This  architectural  style  has  certain  advantages.  It  is  highly  maintainable,  be¬ 
cause  the  different  filter  components  have  no  knowledge  of  each  other,  and 
any  of  them  can  be  replaced  without  affecting  the  others.  This  independence 
also  makes  the  filters  very  reusable  elsewhere,  and  allows  them  to  be  imple¬ 
mented  as  concurrent  processes.  The  pipe  and  filter  style  is  also  easy  to  un¬ 
derstand,  corresponding  mathematically  to  a  composition  of  functions.  This 
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model  also  has  its  disadvantages,  however.  !f  user  interaction  is  necessar\’.  it 
does  not  fit  well  into  this  batch-oriented  processing  scheme.  Finally,  the  pipe 
passes  data  down  the  stream  globally,  and  It  must  pasS  all  data  required  at  any 
filter  down  the  entire  stream.  This  model  therefore  necessitates  that  the 
passed  data  be  the  union  of  everything  that  the  different  filters  need,  and  it 
can  be  costly  if  they  have  widely  spread  data  requirements.  In  summary,  the 
pipe  and  filter  architectural  style  is  simple  and  neat,  but  it  can  require  extra 
overhead  and  does  not  v.’ear  well  in  interactive  systems  [GarI93,5-6]. 

The  second  architectural  style  examined  by  Garlan  and  Shaw  is  the  data 
abstracUon  model.  In  this  model,  each  component  is  an  Instance  of  an  abstract 
data  type,  and  is  termed  a  manager  because  It  is  responsible  for  maintaining 
its  own  state,  and  it  keeps  this  state  hidden  from  other  components.  Connec¬ 
tors  in  this  style  are  Implemented  through  subroutine  calls,  as  are  common  to 
many  block  structured  languages.  Object-oriented  architeaures  are  a  special 
case  of  the  data  abstraction  model,  and  the  advantages  of  data  abstraction  have 
already  been  described  in  excoriating  detail  in  Section  2.1.  The  most  signifi¬ 
cant  disadvantage  of  the  data  abstraction  model  is  that  in  order  to  interact  with 
a  component,  the  identity  of  that  component  and  its  connectors  must  be  known 
and  visible.  This  problem  negatively  affects  modifiability,  because  a  change 
in  the  identity  of  a  component  causes  a  ripple  effect  throughout  the  system,  as 
every  other  component  dependent  on  the  changed  component  must  also  be 
altered  [Garl93,7-8]. 

Of  special  interest  to  this  research  effort  is  the  Garlan  and  Shaw  view 
that  inheritance  Is  a  method  for  organizing  components,  not  of  connecting 
them  lGarl93,8].  Regardless,  a  special  kind  of  object-oriented  architecture, 
called  an  application  framework,  is  often  used  within  the  object-orientea 
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community  [Str91].  This  mode!  provides  a  base  set  of  abstract  or  default  com¬ 
ponents  within  a  panicular  problem  area,  or  domain.  From  this  base  set,  a 
system  developer  can  use  inheritance  to  derive  components  necessar>’  for  the 
architecture  they  foresee  for  their  specific  application. 

The  third  architectural  style  that  Garlan  and  Shaw  examine  is  the 
event-based  architecture.  This  model  uses  components  verj'  similar  to  the  data 
abstraction  model,  but  these  components  are  connected  in  an  entirely  differ¬ 
ent  manner.  Whereas  the  earlier  style  required  explicit  calling  of  another 
component's  subroutines,  the  event-based  model  broadcasts  requests  for  ser¬ 
vice  throughout  the  system.  The  system,  responsible  for  m.anaging  which 
components  are  interested  in  which  broadcasts,  then  implicitly  invokes  the 
necessary'  components  and  the  data  is  passed  accordingly.  The  event-based 
model  has  Its  advantages  through  component  independence,  as  each  com.po'- 
nent  is  abstract  and  encapsulated,  and  can  be  reusable  or  concurrent.  The 
main  disadvantage  is  lack  of  event  ordering  and  determinism,  as  the  system 
cannot  guarantee  the  sequence  in  which  connections  are  made,  or  that  they 
get  made  within  a  particular  length  of  time.  To  correct  for  this  problem,  most 
event-based  systems  also  allow  explicit  invocation.  Another  practical  disad¬ 
vantage  of  this  Style  Is  the  overhead  incurred  because  the  system  must  manage 
the  implicit  calls  [Garl93,8-9]. 

The  final  style  that  this  section  looks  at  in  detail  is  the  layered  architec¬ 
ture.  This  style  organizes  its  components  hierarchically,  with  each  layer 
providing  services  to  the  layers  above  it,  and  acting  as  a  cHeni  to  the  layers 
below  it.  In  the  ideal  layered  system,  each  layer  only  has  visibility  to  the  lay¬ 
ers  directly  above  and  below  it,  effectively  encapsulating  each  layer  as  the  hi¬ 
erarchy  extends  upward.  The  connections  in  a  layered  mode!  are  once  again 
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usually  achieved  through  means  of  subroutine  calls.  In  addition  to  reaping 
the  benefits  of  abstraction  and  encapsulation,  layered  models  also  positively 
impact  modifiability.  Because  of  limited  scope,  a  modification  only  affects  the 
layers  directly  connected  to  the  point  of  change.  There  are  also  disadvantages 
to  the  layered  style.  Not  all  systems  lend  themselves  to  a  layerec  breakdown, 
and  those  that  do  are  susceptible  to  high  coupling  between  laj'ers.  Efficiency 
losses  can  be  large  when  an  upper  layer  must  go  through  multitudes  of  other 
layers  to  get  at  functionality  implemented  at  a  much  lower  layer  [GarI93,9-10]. 

Garlan  and  Shaw  continue  to  describe  different  architectural  styles  that 
are  used  less  often  in  industry  [GarI93,10'!3].  They  conclude  their  discussion 
of  the  different  styles  by  pointing  out  that  most  large  applications  are  de¬ 
signed  combining  more  than  one  style.  This  intertwining  often  ;s  accom¬ 
plished  by  using  an  encapsulated  hierarchy,  with  each  level's  implementation 
being  hidden  from,  and  therefore  irrelevant  to,  the  other  levels.  This  hetero¬ 
geneous  stj'le  takes  advantage  of  each  architectural  model  in  the  areas  in 
which  it  Is  strong,  and  does  not  force  a  style  to  be  used  in  a  situation  in  which 
It  has  shortfalls  lGarl93,13]. 

Having  concluded  the  pedagogical  discussion  of  architectures,  discus¬ 
sion  now  turns  to  architectures  that  exist  in  the  real  world. 

2.3  Current  Industrial  Simulation  Architectures 

This  section  describes  software  architectures  used  in  the  visual  simulation  in¬ 
dustry  todaj'.  The  search  for  this  information  is  partly  obscured,  however,  be¬ 
cause  of  the  proprietary  nature  of  the  field.  Traditional  producers  of  flight 
simulators,  such  as  CAE-Link  and  Evans  &  Sutherland,  rightfully  do  not  care  to 
divulge  the  details  of  innovations  that  give  them,  an  advantage  in  the  market- 
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place.  Luckily,  they  have  agreed  to  share  some  high  level  knowledge,  and 
other  organizations  have  published  summaries  of  the  software  architecture 
work  done  at  these  corporations  [Epp94J.  The  main  players  in  the  dissemina¬ 
tion  of  this  information  are  the  Software  Engineering  Institute  at  Carnegie 
Mellon  University  and  the  Training  Systems  Program  Office  of  the  Air  Force's 
Aeronautical  Systems  Center  (ASCAT)  IAbo93,  ASC93,  SEI93]. 

As  the  primary  Air  Force  agency  responsible  for  the  procurement  of 
flight  simulators,  ASCAT  has  years  of  experience  with  these  complex  training 
de\4ces.  It  also  has  quite  a  stake  in  ensuring  that  suppliers  can  implement  the 
software  aspects  of  flight  simulators  efficiently  and  inexpensively.  In  1986, 
ASC/YT  realized  that  simulator  software  systems  were  outgrowing  their  origi¬ 
nal  designs,  and  that  modifications  due  to  changing  requirements  were 
becoming  more  and  more  impractical.  The  added  complexity  also  forced 
simulator  vendors  to  rely  on  subcontraaors.  and  the  resultant  geographic  and 
organizational  disparity  Introduced  Inconsistencies  into  the  development 
process.  In  order  to  correct  these  problems,  ASCAT  began  to  oversee 
Investigations  into  the  design  of  a  common  flight  simulator  software 
architecture,  or  what  it  termed  a  structural  model  l.^bo93,  ASC93,2]. 

The  basic  structural  model  has  evolved  since  itf  inception,  and  has  re¬ 
cently  been  adjusted  to  incorporate  the  lessons  learned  from  the  development 
of  the  B-2  and  C-17  aircraft  systems  trainers  IASC93,23.  Boeing’s  Defense  and 
Space  Group  has  also  adopted  the  struaural  modeling  method,  and  has  started 
to  release  results  of  using  the  technique  in  simulations  of  various  fighter  air¬ 
craft,  fire  control  units,  and  missile  simulation  systems  (Crl94,280]. 

Technically,  the  structural  model  ser\’es  as  "a  pattern  for  specifying 
and  Implementing  software  S3’stem  functionality"  [ASC93,5J.  The  two  main  aS’ 
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peers  of  ASCAT's  siructural  model  are  partitioning  and  coordination,  and  they 
correspond  directly  to  the  components  and  connections  described  in  Section 
2.2.  Partitioning  refers  to  the  strategy  that  systems  analysts  use  to  divide  a 
complex  problem  into  smaller,  less  complex,  and  more  m.anageable  pieces.  Co¬ 
ordination  involves  the  method  by  which  the  partitioned  components  interact 
with  each  other.  Establishing  strategies  for  partitioning  and  coordination  en¬ 
courages  consistency'  and  eases  integration  by  giving  the  numerous  members 
of  a  development  team  a  common  implementation  plan  from  which  they  can 
work.  Different  partitioning  and  coordination  strategies  may  all  lead  to 
proper  system  functionality,  but  they  may  also  vary  in  their  attainment  of 
basic  software  engineering  goals  like  modifiability,  reusability,  and  effi¬ 
ciency.  Because  these  goals  are  often  contradictory,  the  software  systems  de¬ 
velopers  will  have  to  evaluate  which  goals  pertain  to  their  simulator  project, 
and  choose  the  strategy'  most  suitable  for  their  particular  needs.  ASCAT  calls 
its  software  architecture  a  model  because  It  permits  rapid  establishment  of 
partial  solutions  that  resemble  the  desired  system.  These  models  can  be  evalu¬ 
ated  inexpensively  and  adjusted  incrementally  until  the  end  product  is  finally 


achieved  IASC93,  5-11], 

Boeing  calls  its  latest  incarnation  of  the  structural  model  the  Domain 
Architecture  for  Reuse  in  Training  Systems  (DARTS).  D.ARTS  partitions  the 
problem  space  of  a  flight  simulator  into  twelve  segments,  each  of  which  corre¬ 
sponds  to  a  flight  simulator  subproblem.  Examples  of  these  subproblems  in¬ 
clude  flight  dynamics,  radar,  and  propulsion.  Each  segment  is  funher  divided 
into  components  which  represent  air  vehicle  parts  or  functions.  The  design¬ 
ers  of  DARTS  consider  the  coordination  aspect  of  the  struaural  model  "of 
paramount  importance."  Traditional  simulation  systems  have  used  global  in- 
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terfaclng  between  componerts,  but  coordination  must  be  "defined  and  con¬ 
trolled"  to  ensure  correct  functionality  and  reliability  (Cri94,273].  Because  of 
this  belief,  DARTS  coordinates  its  segments  by  using  message  passing  as  op¬ 
posed  to  shared  memory.  Although  shared  memcr}'  is  generally  faster,  mes¬ 
sage  passing  is  less  dependent  on  hardware  platforms.  Deciding  to  use  a  coor¬ 
dination  strategy  that  values  reliability  and  portability  over  efficiency  Is  the 
first  step  in  creating  a  software  architecture  that  can  tm!}’  be  applied  in  mul¬ 
tiple  environments  [Cri92,2-5]. 

The  techniques  of  both  ASCAT  and  Boeing  give  an  architecture  that  is 
too  complete  for  any  real  system.  They  model  every*  known  aspea  of  the  flight 
simulator  domain,  so  that  nothing  will  be  overlooked  on  any  particular  flight 
simulator.  Each  development  team  will  then  have  to  hone  or  tailor  the  archi¬ 
tecture  to  fit  its  application.  This  approach  is  in  keeping  with  the  general 
trend  in  the  field  of  domain  analysis  [Cri92.5]. 

It  is  surprising  that,  despite  the  current  development  trends,  neither 
the  ASC/YT  nor  the  Boeing  architecture  is  overly  objea-oriemed.  The  Boeing 
team  states,  "Note  that  the  analysis  that  produces  the  final  architecture  begins 
with  functional  decomposition  and  ends  with  what  can  sensibly  be  described 
as  objects"  [Cri92,5].  The  flight  simulator  systems  contractors  have  basically 
chosen  to  exploit  the  advantages  of  both  the  functional  and  object-oriented 
programming  methodologies.  Partitioning  can  occur  at  the  base  level  until 
simple,  low-level  objects  can  be  designed  and  Implemented.  At  the  higher 
level,  coordination  dictates  ••  n  easily  understood  flow  of  control,  which  is  more 
easily  analyzed  in  a  funalonal  manner. 

The  discussion  of  background  topics  now  moves  from  simulation  archi¬ 
tectures  to  the  Performer  graphics  programming  librar}*. 
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2.4  The  Silicon  Graphics  IRIS  Performer  Library 


IRIS  Performer  (Performer)  lCoo92,  McL92,  nar94]  Is  a  toolkit  that  allows 
graphics  programmers  to  create  high  performance  applications  on  Silicon 
Graphics  hardware  systems.  It  is  built  on  top  of  the  existing  !R!S  Graphics  Li- 
brar\'  (Gl)  tMcL91],  which  eases  low-level  rendering  on  SGI  platforms.  Per¬ 
former  supports  two  seemingly  orthogonal  objectives:  building  applications 
more  easily  through  a  well-defined  programmer  interface  and  increasing 
performance  of  any  GL  application.  It  turns  out,  however,  that  since  Per¬ 
former  combines  optimization  with  abstract  calls  to  modules,  both  of  these  ob¬ 
jectives  are  actually  intermingled.  Performer  therefore  greatly  enhances  the 
productivity  of  graphics  programmers  by  allowing  them  to  minimize  devel¬ 
opment  time  for  their  applications  and  automatically  maximizing  the  visual 
impaas  and  effeas  of  their  efforts. 

Although  Performer  factors  out  many  of  the  tasks  necessary  in  graph¬ 
ics  programming,  it  does  not  constrict  the  application  developer's  creativity. 
The  dynamics  of  the  visual  simulation  objects  are  still  left  to  the  developer, 
who  has  the  freedom  to  define  the  entire  feel  of  the  project.  The  basis  of  the 
developer's  creativity  lies  In  the  models  she  uses  to  represent  the  entities  in 
her  simulation.  These  models  arc  usually  established  by  using  a  three  dimen¬ 
sional  modeling  tool,  which  stores  the  geometric  representation  of  an  entity  in 
a  database.  Performer  supports  many  different  modeling  tools,  reading  their 
databases  and  translating  them  into  data  struaures  which  it  renders  to  pro¬ 
duce  an  application.  The  primarj'  modeling  too!  used  in  the  .^FIT  Graphics  Lab 
is  called  MuItiGen,  and  it  is  developed  by  Software  Systems  [Mul92}. 

Performer's  magic  is  created  through  the  means  of  uvo  main  libraries, 
the  first  of  which  is  called  pr.  The  code  to  optimize  the  visual  impact  of  the 
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graphics  rendering  is  kept  In  this  low-levp!  library.  It  contains  functions 
that  are  vital  to  concurrent  real-time  graphics  programming.  Including 
highly  optimized  math  functions.  genmetr>’  processing  routines,  sophisticated 
state  management  techniques,  meniors’  allocation  techniques,  and  other  ren¬ 
dering  tricks.  .Although  these  concepts  are  rather  simple  to  fathom,  the  intri¬ 
cacies  needed  to  make  subtle  improvements  in  their  performance  can  be  quite 
complex.  .Acknowledging  this  fact,  Performer  provides  abstract  calls  to  these 
functions,  and  Implements  the  details  Itself,  allowing  the  applications  devel¬ 
oper  to  concentrate  on  less  mundane  activities. 

The  second  Performer  library’,  pf,  holds  the  code  that  allovs’S  the  appli¬ 
cations  programmer  to  easily  access  visual  simulation  functions.  This  library’ 
also  defines  a  rendering  tree  data  siruaure  for  holding  the  entities  being  rep¬ 
resented  In  Che  scene,  as  well  as  the  means  to  methodically  traverse  this 
structure.  When  told  to  do  so,  Performer  assimilates  the  model  databases  de¬ 
scribed  above  Into  the  rendering  tree,  so  that  they  can  be  properly  displayed 
In  the  scene.  It  is  important  to  note  that  the  pf  library-  totally  encompasses  the 
pr  library',  and  because  of  this  structure,  the  client  programmer  can  access  all 
Performer  funalonality  either  directly  or  Indirectly  through  pf. 

Visual  simulation  applications  are  Implemented  by  Performer  In  the 
pipe  and  filter  manner  described  in  the  section  above  on  software  architec¬ 
tures.  This  pipelining  allows  extremely  efficient  multiprocessing,  exploiting 
as  many  processors  as  are  available  to  increase  the  computational  throughput. 
Performer  continually  repeats  a  three  step  algorithm  that  traverses  the  ren¬ 
dering  tree  structure  and  its  corresponding  scene.  The  first  step  in  this  al¬ 
gorithm,  application,  actually  moves  the  objects  in  the  scene  by  conducting 
the  necessary  calculations,  -nd  Is  defined  by  the  programmer.  The  second 
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step,  cull,  moves  through  the  tree  deciding  which  objects  are  inside  the  field 
of  \hsion  and  therefore  need  to  be  drawn.  The  cull  step  builds  a  display  list  of 
these  objects.  The  final  step,  draw,  renders  the  objects  in  the  display  list.  The 
fact  that  these  three  steps  are  separate  makes  it  pos-sible  to  split  them  into 
threads  and  take  advantage  of  multiprocessor  machines.  If  this  optimization 
can  be  accomplished,  however.  Performer  does  so  automatically  and  the  appli¬ 
cation  programmer  need  not  be  concerned  with  any  details. 

By  default,  the  complicated  and  tedious  cull  and  draw  processes  are  ac¬ 
complished  automatically  by  Performer.  However,  an  application  developer 
may  customize  these  processes  through  an  established  method  of  callbacks. 
The  programmer  prox'ides  his  own  functions  for  culling  and  drawing,  and  no¬ 
tifies  Performer  of  their  existence  during  Performer  initialization.  During 
the  simulation,  Performer  calls  his  functions  at  the  appropriate  time*  and  the 
customization  occurs.  This  Performer  feature  is  useful  If  certain  entities 
within  the  simulation  must  react  to  input  devices,  which  are  usually  read  on 
the  draw  thread,  or  have  specialized  output  requirements.  Callbacks  are  also 
used  by  Performer  and  GL  to  perform  window  management. 

Finally,  Performer  has  some  other  important  features  which  applica¬ 
tion  developers  can  use.  Chanrtels  can  be  used  by  the  programmer  to  set  up 
different  views  Into  a  scene,  as  If  various  observers  were  watching  from 
completely  different  angles.  Multiple  views  are  also  useful  if  entirely  differ¬ 
ent  repiesematlons  of  a  scene  are  necessary'.  For  example,  when  simulating  a 
radar  in  a  plane's  cockpit,  both  the  radar  screen  and  the  canopy  provide  views 
of  what  Is  occurring  outside  the  plane,  but  these  two  "windows"  display  the 
scene  in  utterly  distina  fashions.  In  addition  to  multiple  view  handling.  Per¬ 
former  provides  mechanisms  for  using  shared  memor>'  to  enhance  processing 
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speed  through  the  pipes.  This  feature  allows  developers  to  hone  the  perfor¬ 
mance  of  their  applications.  Other  features  in  Performer  allow  the  developer 
to  include  such  features  as  collision  detection,  sequenced  animations,  atmo¬ 
spheric  effects  like  fog  or  haze,  or  light  sources  to  imitate  beacons,  stars,  and 
sunlight. 

This  section  has  provided  a  brief  overview  of  Performer  and  its  capa¬ 
bilities.  More  complete  coverage  can  be  found  in  the  documentation  for  Per¬ 
former  and  its  related  tools  (Coo92,  Har94,  McL91,  Mul92].  Discussion  now  fo¬ 
cuses  on  ObjectSim,  the  architecture  that  was  created  in  the  AFIT  Graphics  Lab 
by  Mark  Snyder  to  proNide  further  abstraction  on  top  of  Performer. 

2,5  ObjectSim  Concepts 

Since  1989,  the  /\FIT  Graphics  Lab  has  been  sponsored  by  the  .Advanced  Re¬ 
search  Projects  Agency  (ARPA)  to  investigate  low-cost  distributed  interactive 
simulations.  As  technology  ha.s  progressed  since  then,  so  have  the  capabilities 
of  the  applications  produced  by  the  score  of  graduate  students  who  have 
worked  in  the  Lab.  However,  this  Increase  in  capability  has  been  accompanied 
by  a  corresponding  increase  in  software  complexity.  In  the  academic  cycles 
ending  in  1991  and  1992,  it  became  apparent  that  the  students  were  spending 
more  time  redoing  tasks  common  to  all  visual  simulations  than  developing  so¬ 
lutions  for  their  particular  projects.  Patricia  Lawlis,  Assistant  Professor  of 
Software  Engineering  at  AFIT,  became  involved  in  the  research  In  1992  to  at¬ 
tempt  to  manage  a  reuse  effort  within  the  Lab.  Reuse  would  allow  the  students 
to  concentrate  more  of  their  efforts  on  their  specific  simulations,  instead  of 
recreating  common  graphics  functionality.  Lawlis  enlisted  the  help  of  her 
student,  Mark  Snyder,  and  he  produced  the  ObjectSim  fram.ework  to  curb  the 
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complexity  problems  in  the  Lab.  This  section  outlines  the  basic  design  of  Ob- 
jectSim  [Sny93]. 

Snyder's  primary  task  was  to  factor  out  the  commonalities  between  the 
four  ongoing  projects  within  the  Graphics  Lab  [Eri93,  Gard93,  Ger93,  Kun93, 
S0I93,  Wil93].  He  began  his  effort  by  examining  components  that  already  ex¬ 
isted,  to  see  if  they  could  be  reused.  His  survey  quickly  revealed  that  these 
components,  developed  for  specific  applications,  were  not  malleable  enough  to 
use  on  varied  projects.  Snyder  realized  that  it  would  be  more  productive  to 
make  reusable  components  from  scratch  (Sny93,31-32].  Of  notable  exception 
were  the  network  communications  components;  which  were  reused.  The 
probable  reason  for  this  exception  is  that  the  original  designer  of  these  com¬ 
ponents,  Steven  Sheasby,  has  been  maintaining  them  since  their  inception 
IShe92,  She94].  He  could  therefore  ser\’e  as  living  documentation  to  define 
their  use,  w'hereas  the  knowledge  necessary  to  use  the  other  components  had 
disappeared  with  the  graduation  of  their  designers.  The  network  communica¬ 
tion  components  were  never  completely  integrated  into  ObjectSim,  however. 

After  determining  what  he  could  reuse,  Snyder  performed  a  require¬ 
ments  analysis  by  talking  with  the  other  students  in  the  Graphics  Lab. 
Through  this  analysis  he  w'as  able  to  establish  the  functionalitj’  that  was  com¬ 
mon  to  everj'  application  {Sny93, 32-331.  Snyder  decided  to  allow  the  other  stu¬ 
dents  to  access  these  common  capabilities  by  means  of  an  application  frame¬ 
work.  This  programming  paradigm  provides  an  avenue  for  software  reuse,  but 
at  the  domain  level  instead  of  the  traditional  component  level.  Within  the  do¬ 
main,  the  components  of  the  framework  provide  templates  from  which  actual 
components  can  be  derived  and  customized.  The  framework  therefore  "pro¬ 
vides  major  savings,"  as  the  basic  architecture  for  the  code  already  exists 
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[Sny93, 39*40].  Not  surprisingly,  components  of  an  application  framework  are 
often  implemented  as  abstract  classes  in  object-oriented  programming  lan¬ 
guages. 

Snyder  began  lo  rapidly  develop  ObjectSim  by  incorporating  compo¬ 
nents  donated  by  the  other  six  students.  He  also  developed  generalized  imple¬ 
mentations  of  common  components  on  his  own.  Snyder  designed  test  applica¬ 
tions  to  evaluate  new  functionality,  and  through  this  methodology  he  was  able 
to  quickly  coerce  the  Virtual  Cockpit  to  rely  on  the  ObjectSim  framework.  The 
other  applications  followed  soon  thereafter  {Sny93, 40-44]. 

In  terms  of  architectural  style,  ObjectSim  belongs  to  the  data  abstraaion 
model.  Its  object-orientation  defines  abstract  interfaces  to  different  compo¬ 
nent  classes,  with  straight  function  calls  acting  as  connectors.  The  use  of  ab¬ 
stract  classes  determines  the  basic  architeaura!  structure,  and  forces  the  ap¬ 
plication  developer  to  adhere  to  the  provided  scheme  for  components  and  con¬ 
nections  in  order  to  benefit  from  the  framework.  While  ObjectSim  Itself  ad¬ 
heres  to  the  data  abstraaion  model.  Its  use  of  the  pipe  and  filler  Performer  ar¬ 
chitecture  makes  the  entire  system  heterogeneous.  The  fact  that  Performer  is 
kept  separate  from  ObjectSim,  with  interaction  again  occurring  by  function 
calls,  adds  layering  into  the  system  as  well.  Under  Performer  are  iwo  lower 
layers,  one  for  GL  and  one  for  the  IRIX  operating  system,  but  they  exist  at  a 
level  of  abstraction  below  what  is  examined  in  this  thesis.  Figure  14  shows  the 
architeaural  layering  of  ObjeaSim. 
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Application 

ObjectSim 

Silicon  Graphics  IRIS  Performer  1.2 
Silicon  Graphics  Graphics  Library'  5.2 
Silicon  Graphics  IRIX  Operating  System  5.2 


Figure  14.  ObjectSim  Architectural  Layering 

Figure  15  shows  the  ObjectSim  Object  Model.  The  main  objects  in  the 
application  framework  and  the  relations  between  them  are  indicated  in  the 
Rumbaugh  diagram.  The  most  basic  object  is  the  Flt_Model,  which  stores 
database  information  describing  how  an  object  appears  graphically.  A  Ter¬ 
rain  ser\'es  as  the  visual  background  for  an  application.  A  Simulation  serv’es 
as  the  basis  for  an  application  and  encompasses  a  Terrain  and  any  number  of 
Players,  the  entities  whose  interaction  define  the  graphics  application,  A 
View  allows  vision  into  the  application's  scene,  and  a  Modifier  can  be  used  to 
move  a  View  around  the  scene.  Finally,  the  Pfmr.Renderer  controls  the  actual 
drawing  by  making  the  necessary'  Performer  calls. 
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Simulation  Class 

•  Superd  ass  fcr  apptication 

-  V  ewpdnt  user  interface 

-  Execsimulation  control 


Pfmrjl  enderer  Class 

-  Executive  (pntrd 

-  Common  geometry  list 
•  Graphics^vindow  mgmt 
-MultiprocEss.mgmt 


Terrain  Class 
-Timeof  daymgmt 
-Sky  and  ground 
-  F  eatires 
-Placement on  tfdbe 


-Viewpoint  calculations 
-  Multiple  windowXficwpoint 
diannelmgmt 


Player  Class 
I  -  Superclass  fa  sim  entities 

I  -  Inherited  dasses  create 
usefti  subclasses  like 
-  Nelwak  Player 
-  Steath  View  Player 


represents 


Modifier  Class 

-Template  fa  certain 
device  interface 
-  Trackers /spaceball 


Fit-Model  Class 

-  Geometry  represertation 
fa  Players 

-  M  ana  ges  instances  of 
geonetfy 


rigure  15.  ObjectSim  Objca  Model  lSn>'93,45] 


The  Terrain,  Simulation,  Player,  and  View  classes  of  the  ObjectSim 
framework  are  abstract.  This  approach  allows  application  developers  to  cus¬ 
tomize  their  simulations  freely  while  letting  them  exploit  proven  methods  and 
algorithms.  It  also  encourages  developers  to  produce  standardized  applica¬ 
tions,  making  them  more  interoperable  and  modifiable.  Two  of  the  concrete 


classes  were  not  intended  to  be  portable,  as  their  names  reflect.  Flt-Model 
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algorithms.  It  also  encourages  developers  to  produce  standardized  applica¬ 
tions,  making  them  more  interoperable  and  modifiable.  Two  of  the  concrete 
classes  were  not  intended  to  be  portable,  as  their  names  refiect.  FIt_Model 
handles  Flight  format  models  created  using  the  MuUiGen  visual  database  de¬ 
velopment  tool,  and  the  Pfmr^Renderer  is  intended  to  isolate  the  Simulation’s 
dependency  on  the  Performer  library'. 

While  this  summary  has  simplified  ObjectSim  in  many  ways,  it  does  con¬ 
vey  the  general  ideas  behind  its  development.  ObjectSim  was  an  unqualified 
success  In  the  AFIT  Graphics  Lab,  increasing  student  productivity  between 
thirty  and  forty  percent  [Sny93,79].  The  next  chapter  looks  at  ObjectSim  more 
closely  in  order  to  develop  its  successor,  Easy^Sim. 
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ni  Architectural  Design 

This  chapter  relates  the  analysis  performed  on  the  ObjectSim  architecture  and 
the  lessons  that  were  learned  from  it  and  applied  to  the  formation  of  Easy^Sim, 
a  language  independent  software  arciiitecture  for  visual  simulation  systems. 
This  chapter  firsts  analyzes  the  advantages  and  disadvantages  of  the  method 
Mark  Snyder  used  to  develop  ObjectSim.  and  then  describes  the  radically  dif¬ 
ferent  method  used  for  Easi'_Sim.  The  majority  of  this  chapter  describes  the 
Easy_Sim  classes  and  their  relationships.  This  task  Is  accomplished  by  exarnin- 
Ing  each  component  of  ObjectSim,  retaining  its  positive  points,  and  modifying 
its  negative  aspects.  The  chapter  concludes  by  presenting  the  final  Easy_Sim 
Object  Model,  and  examining  the  overall  design  of  the  Easy_S!m.  architecture. 

3.1  The  Design  Processes 

Mark  Snyder  developed  ObjectSim  with  four  large  simulation  projects  and  six 
other  students  reliant  on  his  success.  This  pressure  and  dependence  had  both 
positive  and  negative  effeas  on  his  design  efforts.  This  section  describes  how 
Easy_Sim  benefited  from  ObjectSim’s  achievement  while  tr>’ing  to  avoid  its  pit- 
falls.  It  first  examines  the  method  used  for  developing  ObjectSim,  then  out¬ 
lines  the  diametrically  opposed  approach  used  with  Easy_Sim. 

3.1.1  The  ObjectSim  Development  Method 

.Mark  Snyder  created  ObjectSim  according  to  what  he  termed  the  necessity 
model  [Sny93,44].  When  the  Graphics  Lab  projects  were  originally  converted 
to  use  ObjectSim,  Snyder  analyzed  their  components  for  inclusion  in  the 
framework.  Classes  deemed  suitable  were  generalized  and  incorporated  into 
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ObJectSim.  Alternatively,  if  a  student  desired  new  functionality  in  his  appli¬ 
cation,  he  would  implement  a  solution  locally,  and  Snyder  would  evaluate  the 
utility  of  the  new  code  for  ever>'one,  once  again  incorporating  it  if  it  promised 
to  "promote  the  general  welfare." 

Snyder's  necessity  model  allowed  a  tremendous  number  of  ideas,  designs 
and  components  to  be  considered  for  ObjectSim,  and  enabled  them  to  be  consid¬ 
ered  early  In  the  thesis  life  cycle.  The  amount  of  useful  code  in  the  Lab  was 
able  to  expand  rapidly  because  of  this  technique.  More  importantly,  the  code 
brought  into  ObjectSim  was  tested  in  numerous  applications,  so  any  defects 
were  rapidly  deteaed  and  eliminated. 

While  the  necessity  model  allowed  the  general  productivity  in  the 
Graphics  Lab  to  increase  dramatically,  it  also  had  some  negative  effects.  Be¬ 
cause  of  the  dynamic  nature  of  the  framework,  the  other  students  often  had  to 
suspend  their  own  projects  to  Incorporate  new  versions  of  ObjectSim.  Config¬ 
uration  management  problems  occurred  frequently  [Sny93,li].  With  seven 
individuals  contributing  code,  conflicts  in  style  and  convention  were  common. 
Unfortunately,  these  conflicts  were  carried  into  the  framework,  and  because 
the  changes  needed  to  be  made  quickly,  standardization  was  often  performed 
hastily.  Many  of  ObjeaSim's  component  and  connector  names  remain  incon¬ 
sistent.  The  haste  associated  with  version  updates  also  had  a  more  long  lasting 
side  effect"it  created  an  oral  culture  within  the  Lab,  Modifications  were  sug¬ 
gested,  made,  and  forgotten  before  their  rationale  was  documented.  ObjectSim 
Is  currently  filled  with  enigmatic  code  that  seemingly  does  nothing,  but  whose 
removal  causes  utter  destruction. 

The  reader  may  have  noticed  a  shift  during  discussion  of  the  necessity 
model.  It  lowered  the  focus  of  ObjectSim's  developm.ent  from  the  analysis  and 
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design  level  to  the  code  level.  Unfortunately,  the  necessity  model  was  often 
reactive  when  it  should  have  been  guiding,  letting  the  implementation  drive 
the  design.  This  shift  is  evident  when  ObjectSim  is  evaluated  thoroughly,  es¬ 
pecially  in  the  area  of  network  interaction.  Because  the  Graphics  Lab  de¬ 
pended  on  a  contractor  to  handle  this  area  of  their  projects,  network  interac¬ 
tion  capabilities  were  never  completely  incorporated  Into  ObjectSim.  This  di¬ 
vergence  resulted  in  network  components  that  handled  interaction  differ¬ 
ently  for  each  application.  Anytime  new  functionality  was  added,  kludges  had 
to  be  introduced  in  many  places,  including  the  basic  ObjectSim  framework 
[Sny93,57,  She94].  The  intermingling  of  implementation  and  de.sign  is  also 
evident  In  Snyder's  thesis,  as  his  design  chapter  frequently  refers  to  Imple¬ 
mentation  Issues  [Sny93,Ch4j. 

3.1.2  The  Easy«Slm  Devdopment  Method 

Easy,.Slm  was  developed  without  the  pressure  of  any  other  students  reliant  on 
Its  results,  as  the  five  students  working  concurrently  used  the  existing  Object¬ 
Sim  framework.  This  decision  was  made  consciously  because  of  the  risk  in¬ 
volved  with  the  primary  implementation  of  Easy_Sim  occurring  with  an 
untested  language  in  an  untested  environment.  Accordingly,  Eas3'_Sim  was 
designed  with  a  set  of  circumstances  completely  reversed  from  the  ObjectSim 
case.  This  seaion  briefly  describes  those  differences,  and  concludes  by  outlin¬ 
ing  design  decisions  common  to  all  Easy_Sim  classes. 

Where  the  production  of  ObjectSim  benefited  immensely  from  having 
seven  developers  simultaneously  recognizing  requirements,  contributing  de¬ 
signs,  and  testing  solutions,  Easy_Sim  is  primarily  Implemented  as  a  solo  effort. 
Its  requirements  are  drawm  by  trjing  to  match  ObjectSi.m  functionality  and 
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conversing  with  the  current  students,  but  no  code  has  been  donated  through 
this  method.  The  Easy_Sim  implementation  draws  some  Ideas  and  code  from  a 
demonstration  program,  PaintbaU,  under  development  at  Silicon  Graphics  by 
Wes  Embry-  and  John  Templeton  (Emb94].  This  effort  convens  an  Ada  83  pro¬ 
gram  to  Ada  9X,  but  does  not  exploit  the  object-oriented  capabilities  of  the  new 
language.  Paintball's  contributions  to  the  Easy.Sim  architectural  design  are 
therefore  limited.  Consequently,  Easy_Sim  has  been  developed  much  more 
slowly  and  with  much  less  implementation  testing  than  ObjectSim,  but  with 
considerations  for  it  to  be  language  Independent. 

The  development  method  for  Easj'_Sim  does  have  its  advantages,  how¬ 
ever.  Because  the  design  is  not  influenced  by  the  need  to  be  rapidly  inte¬ 
grated,  it  remains  more  pure.  Us  development  by  one  individual  also  makes 
the  components  and  connectors  more  standardized,  and  configuration  man¬ 
agement  is  not  a  faaor.  Finally,  design  decisions  are  documented  both  in  this 
document  and  in  the  code,  so  that  continuing  work  both  at  AFIT  and  elsewhere 
will  be  able  to  understand  Easy_Sim's  evolution. 

This  section  has  analyzed  the  positive  and  negative  aspects  of  the  Ob- 
jeaSim  and  Easy_Sim  archlteaural  design  methods.  Before  the  design  of  each 
class  is  detailed,  the  next  section  outlines  the  overall  conventions  used 
throughout  the  entire  Easy.Slm  design. 

3.2  Easy_Slin  Class  Design  Conventions 

The  classes  in  Easy_Sim  are  designed  using  the  design  level  ideas  of  the 
ROMAN-9X  technique  (see  Section  2.1.4).  This  method  keeps  the  different 
classes  consistent  by  providing  standardized  naming  conventions  and  con¬ 
structs,  and  It  enhances  the  definition  of  the  data  abstraction  architecture’s 
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components  and  connectors  (see  Section  2.2).  Each  class  has  default  initializa¬ 
tion  and  finalization  operations,  a  parameterized  Initialization  operation  called 
Configure,  and  Get  and  Set  operations  as  appropriate  for  its  attributes.  Classes 
that  contain  \isual  models  have  a  special  Get  cperatson,  Image,  which  returns 
the  node  in  the  rendering  tree  corresponding  to  the  root  of  the  object’s 
graphical  representation.  The  existence  of  the  Get  and  Set  operations  is  as¬ 
sumed  in  the  remainder  of  this  chapter,  and  no  further  mention  of  them  is 
made.  Most  classes  also  have  an  Update  operation,  which  determines  the  be¬ 
havior  of  an  instance  of  that  class,  and  a  Draw  operation,  which  defines  any 
necessary  class  specific  rendering  functionality.  Both  the  Update  and  Draw 

operations  are  called  each  frame  of  the  simulaTlon. 

Resources  needed  commonly  throughout  the  Easy.Sim  architecture  are 
defined  in  a  common  location.  The  most  visible  of  these  resources  is  Coords, 
the  data  type  used  to  describe  coordinates  in  an  application.  This  type  contains 
the  X,  Y.  and  Z  veaor  values  which  define  the  Position  where  an  entity  exists 
in  the  simulation.  Coords  also  contains  a  vector  referring  to  the  entity’s  Di¬ 
rection  at  its  Position.  This  vector  comprises  three  values  as  we!!:  the  Heading, 
Pitch,  and  Roll  of  the  entity. 

The  rest  of  this  chapter  examines  the  design  of  each  component  within 
ObjeciSim,  examines  any  positive  and  negative  aspects  of  that  des’.g.n,  and  de 
tails  how  that  component  has  been  migrated  into  Easy_Sim.  Each  section  is 
concluded  with  a  Rumbaugh  diagram  showing  the  wo  versions  of  the  class 
next  to  each  other  so  chat  they  can  be  easily  compared.  The  entire  ObjectSim 
Object  Model  [Sn>'93,453  is  presented  as  Figure  15  at  the  end  of  Chapter  II.  Dis¬ 
cussion  begins  with  the  most  basic  classes  and  progresses  through  the  more 
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complex  components.  The  discussion  of  new  Easy^Sim  components  is  inter¬ 
spersed  as  appropriate. 

3.3  The  Flt_Model  Class 


The  intent  of  ObjeaSim's  Flt_Model  class  is  to  provide  the  abstract  capability  of 
handling  the  geometric  models  used  to  represent  images  in  a  visual  simulation. 
The  class  name  is  prefixed  by  ’•Fit"  to  sho^:  that  it  can  only  represent  models 
created  in  MultiGen's  Flight  format  [Sny941  tsee  Section  2.4).  The  main  opera¬ 
tion  of  this  class,  restdmodel,  reads  in  a  Flight  format  database,  converting  it 
into  a  format  that  the  simulation  can  process.  This  conversion  is  handled  by  a 
simple  Performer  operation,  and  it  stores  the  database  into  an  attribute,  root. 
This  attribute  forms  the  base  node  of  the  tree  representing  the  geometry'  for 
the  Model.  FIt.Model  also  contains  a  constructor  for  initialization  purposes. 
Figure  16  shows  the  Rumbaugh  diagram  for  FluModel, 


Since  the  completion  of  ObjectSim,  a  new  version  of  Performer  has  been 
released  [Har94].  This  version  contains  more  flexible  conversions  of  geometry' 
databases,  enabling  this  class  to  become  independent  of  the  Flight  format.  This 
generalization  Is  the  first  change  made  to  this  component  In  Easy^Slm,  and  the 
component  is  renamed  Model  to  reflea  its  added  capabilities.  The  new  archi¬ 
tecture  also  allows  the  reading  of  the  .Mode!  database  to  be  interpreted  as  .a 
form  of  parameterized  initialization,  and  Easy_Sim  therefore  assigns  this 
functionality  to  Model's  Configure  operation. 

In  its  readmodel  operation,  ObjectSi.m’s  Flr^Mode!  class  provides  the 
ability  to  copy  a  model.  This  charaaeristic  enables  a  simulation  to  avoid  inef¬ 
ficient  replication  of  complex  databases  if  two  or  more  entities  share  a  com¬ 
mon  geometric  representation.  For  example,  in  an  airfield  simulation  there 
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Fleure  16.  Model  Class  Objeev  Model  DiaRrams 


may  be  many  similar  F-15s  flying  in  the  area,  but  one  Model  of  an  F-!5  can 
represent  all  these  planes.  ObjeciSlm's  design  of  this  feature  uses  a  straight 
duplication  technique,  which  works  adequately  for  simple  models,  but  fails  on 
models  with  moving  parts.  At  the  airport,  an  arriving  plane  would  have  its 
landing  gear  down  and  visible  while  a  departing  or  circling  plane  would  have 
Its  landing  gear  up  and  hidden  from  view.  ObjectSim's  omission  is  corrected  in 
the  Easy.Sim  Mode!  class,  and  is  available  puhllcl}-  by  means  of  the  Ocnc  op¬ 
eration. 

Finally,  the  ObJcctSlm  design  of  Flt.Model  maintains  a  list  of  all  the 
models  to  be  used  in  an  application.  In  Easy.Sini,  the  Model  class  Is  simplified 
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to  operate  on  a  single  Model,  and  a  ModeLMamgsr  class  is  introduced  to  track 
multiple  instances  of  the  Model  class.  This  change  makes  the  Model  class  con¬ 
sistent  with  other  Easy.Sim  classes  and  is  explained  further  in  Section  3.7. 
Figure  16  shows  a  Rumbaugh  diagram  representing  the  Ea£y_Sim  .Model  class. 

3.4  The  Terrain  Class 

The  abstract  ObjectSim  Terrain  class  is  intended  to  provide  a  tem.plate  so  that 
each  application  can  develop  a  unique  visual  background  in  which  its  Simula¬ 
tion  can  operate.  Features  Intended  to  be  implemented  here  include  lighting 
models,  weather  models,  time  of  day  management,  the  terrain,  and  any  other 
environmental  variables.  ObjectSim  comes  with  a  default  Terrain  subclass. 
Si/np/e_  Terrain,  which  uses  simple  sun  and  horizon  models  as  well  as  a 
Flt_Model  to  represent  the  ground.  Figure  17  diagrams  the  ObjectSim  Terrain 
and  Simple«Terrain  classes. 

The  Terrain  class  is  a  perfect  indicator  of  the  disadvantages  of  Object* 
Sim's  necessity  model  development  method.  Originally  part  of  the  V'irtual 
Cockpit  application  [Erl93,  Ger93]  and  incorporated  into  ObjectSim,  the  de¬ 
scription  of  Terrain  does  not  fit  the  Space  Modeler  lVan94]  application,  which 
uses  stars  and  planets  as  its  background.  The  ObjeaSim  Object  Model  also  does 
not  reflect  the  relationship  between  Terrain  and  FIt_Mode!,  where  Terrain  is 
mysteriously  implemented  as  a  derived  subclass  of  Flt_Model.  This  kludge  al¬ 
lows  a  Flt.Model  to  be  used  to  represent  the  Terrain,  without  explicitly  making 
It  an  attribute. 
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Figure  17.  Ensironment  Class  Objea  Model  Diagrams 


Fortunately,  ObjectSim's  Terrain  class  also  indicates  the  advantages  of 
Snyder's  necessity  model.  The  creation  of  an  abstract  class  clcarl}*  defines  the 
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component  and  connectors  that  a  developer  needs  io  form  a  useful  environ¬ 
ment,  and  Illustrates  an  example  of  the  object-oriented  data  abstraction  archi- 
teaural  style  described  by  Garlan  and  Shaw  [Garl93,7-8]  (see  Section  2.2).  The 
Terrain  class  has  wo  initialization  operations,  clsinp  and  coiifigurc^CuanriQl, 
and  an  abstract  draw  operation.  Simple.Terrain  adds  two  more  initialization 
operations,  build^terrain  and  initialize,  along  with  attributes  to  represent  the 
horizon  and  sun. 

The  use  of  abstract  classes  is  adopted  by  Easy_Siin  for  this  class  and 
throughout  many  of  the  other  classes  in  the  architecture.  Easy_Sim  renames 
the  Terrain  class  Environment  to  indicate  its  more  flexible  capabilities  and 
prominently  shows  the  non-inheritance  based  relationship  between  the  Envi¬ 
ronment  and  Model  classes.  Easy_Sim  assigns  the  functionality  of  the  initial¬ 
ization  operations  to  Initialize  and  Configure,  its  default  and  parameterized 
initialization  operations,  as  appropriate.  Easy.Sim  retains  the  abstract  Draw 
operation. 

The  new  architerture  also  renames  the  default  Simple.Terrain  Terrain, 
for  those  applications  where  the  basic  ground,  sun,  and  henzen  uicdcl  is  sen¬ 
sible.  Easy.Sim  breaks  its  Terrain  class  into  smaller  classes,  however,  provid¬ 
ing  functionality  for  Sun  and  Horizon  classes  separately,  and  making  Terrain 
an  aggregate  containing  these  classes.  This  iucdular  approach  establishes  a 
precedent,  whereby  a  subclass  can  gather  functionality  from  many  smaller 
classes  and  organize  this  functionality  in  one  place  to  suit  the  requirements  of 
the  architecture.  This  method  makes  building  Environments  much  more 
flexible  and  establishes  a  set  of  modules  that  are  reusable  both  at  the  design 
and  code  levels.  Figure  17  shows  a  Rumbaugh  diagram  of  the  Environment 
classes. 
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3.5  The  Player  Class 


ObjectSim's  abstract  Player  class  serves  as  the  base  class  for  defining  the  enti¬ 
ties  whose  interaction  defines  the  simulation.  The  Player  class  follows  the 
same  basic  approach  as  Terrain,  establishing  an  architectural  template  for  a 
component  and  its  connectors.  Each  Player  has  an  attribute  which  defines  co¬ 
ordinates  for  its  position  and  direction  within  the  simulation,  and  three  op¬ 
erations  modify  this  attribute.  One  operation,  move^along.hesdsng,  advances 
the  Player  along  its  current  path  a  given  distance,  while  a  second  operation, 
Icok^at^point,  pivots  the  Player  to  face  a  given  position  within  the  simulation. 
The  propagate  operation  is  abstract,  and  it  is  the  avenue  through  which  a 
subclass  defines  how  the  Player  behaves  during  each  advancing  frame  of  the 
simulation.  The  Player  class  also  pro\1des  an  abstract  initialization  operation, 
init. 

Most  ObJectSim  Players  contain  a  Flt31odel  which  represents  the  Play¬ 
er's  physical  appearance.  Some  Players  may  exist  in  a  simulation  without  rep¬ 
resentation,  however,  purely  existing  to  provide  a  vantage  point  into  the 
scene.  ObjectSim  categorizes  these  Playe.''s  by  calling  them  Steallh^Playem, 
and  they  are  generally  derived  from  another  abstract  Player  subclass  called 
Attachable^Player.  This  class  is  used  for  players  to  which  a  View  can  be  at¬ 
tached,  and  it  contains  attributes  relating  the  position  and  direction  of  the 
View  relative  to  the  Player.  Because  most  Players  within  an  ObjectSim  appli¬ 
cation  can  view  the  scene,  simulations  derive  the  majority  of  their  Pla>’ers 
from  the  Attachable.Player  subclass.  Figure  18  outlines  the  ObjectSim  Player 
classes. 
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Figure  18.  Player  Class  Object  Model  Diagrams 


Easy.Sim  uses  the  sound  design  of  ObjectSim's  abstract  Player  class  in 
defining  it  own  Player  class  with  only  minor  cosmetic  changes.  The  pr(?pagate 
operation  is  equated  with  Easy_Sim’s  standard  Update  operation.  While  some 
other  ObjeaSim  classes  also  use  the  name  propagate  to  denote  the  operation 
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that  updates  an  instance  of  the  class  each  simulation  frame;  this  similar  op¬ 
eration  is  named  inconsistently  throughout  the  ObjeciSim  architecture. 
Easy_Sini  uses  Update  throughout  all  of  its  classes  to  provide  consistent  con* 
nection  protocols  within  the  architecture.  Eas3'_Sim  also  renames  the  Obiect- 
Sim  Plaj'er's  move_along_heading  and  look_at_polnt  operations,  calling  them 
A/ove_ Straight  and  Look^At  respeaively.  Finally,  Easy_Sim  converts  the  init 
operation  so  that  its  functionality  is  achieved  by  the  controlled  Initizlizc  con¬ 
structor. 

The  Attachable_Player  class  is  not  carried  into  Easy.Sim.  The  purpose 
of  this  class  in  ObjectSim  is  to  track  the  position  and  orientation  of  the  View 
that  is  attached  to  the  Player.  The  Easy„.Sim  interpretation  of  these  View  at¬ 
tributes  places  them  within  the  View  class.  Easy_Sim  application  developers 
are  free  to  develop  subclasses  similar  to  ObjectSim’s  Stealth^Playcr  concept  by 
deriving  directly  from  the  Player  class. 

ObjectSim  makes  no  provision  for  standard  protocols  for  handling  mul¬ 
tiple  Players.  Easy_Slm  Introduces  the  Player  ^Manager  class  to  supply  this 
added  functionality,  and  this  class  Is  further  described  In  Sealon  S."/, 

Figure  18  shows  a  Rumbaugh  Object  Model  diagram  of  the  Player  classes. 
Some  of  the  Get  and  Set  operations  for  the  Coords  attribute  have  been  omitted 
for  brevity,  and  are  listed  in  full  with  the  Modifier  class  in  Figure  20. 

3.6  The  View  and  Modifler  Classes 


The  intent  of  ObjectSim's  V'iew  class  is  to  allow  the  users  of  a  Msual  simulation 
to  look  into  the  scene  being  rendered.  Unfortunately,  the  View  class  is  also  a 
victim  of  the  negative  aspects  of  the  necessity  development  model,  and  de¬ 
scription  beyond  Its  purpose  is  rather  clouded.  A  View  must  be  related  t.o  a.n 
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Attachable_Player  with  Us  attached  attribute,  but  this  connection  is  not  shown 
in  the  ObjectSim  Objea  Model.  At  one  point  the  View  class  is  described  as  en¬ 
capsulating  a  single  view  [Sny93,48],  while  the  Object  Model  diagram  labels  it 
as  managing  multiple  views.  Examination  of  the  implementation  shows  the 
former  to  be  true.  ObjectSim's  View  class  operations  include  serv/evv,  which 
updates  the  Views  each  frame,  and  artacfi_to_p/ayer,  which  switches  a  View 
between  different  Players.  The  View  class  also  provides  two  separate  initial¬ 
ization  operations,  alloc^shared  and  new_view. 

To  quickly  clear  a  common  misconception,  a  View  can  be  attached  to  dif¬ 
ferent  players  consecutively,  and  a  scene  can  therefore  be  cbse  rved  from 
many  different  angles  in  a  single  View’  .simulation.  Multiple  Views  are  only 
needed  when  different  aspects  of  the  simulation  need  to  be  observed  simulta¬ 
neously.  Some  examples  include  a  rear  view  mirror  in  a  driving  simulation,  a 
radar  screen  in  a  flying  simulation,  or  an  inset  channel  box  on  a  television 
set.  This  last  example  demonstrates  the  case  where  the  different  View’s  may 
not  be  observing  the  same  scene.  In  order  to  manage  this  complexity,  each 
ObjectSim  V'iew  has  two  Performer  related  attributes,  chan  and  scene,  a  Per¬ 
former  Channel  represents  a  window  in  a  simulation,  while  a  Scene  serx’es  as 
the  root  of  that  Channel's  rendering  tree,  storing  the  graphical  data  seen  in 
each  window. 

The  ObjectSim  View  class  also  pro\ides  operations  which  the  application 
developer  can  use  to  customize  Performer's  cull  and  draw  processes  (see  Sec¬ 
tion  2.4).  Both  the  cull  and  draw  operations  provide  default  behavior  for  each 
window  in  the  simulation,  basically  doing  nothing.  They  do,  however,  define 
points  in  the  architecture  where  the  application  developer  can  modify  this 
behavior.  Customized  culling  can  enhance  the  application’s  performance,  and 
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the  draw  operation  can  add  extra  information  to  the  scene*  such  as  text  over¬ 
lays.  Figure  19  shows  an  Object  Model  diagram  of  the  ObjectSim  View  class. 

In  ObjectSi.*i,  a  View  may  be  associated  with  a  Modifier  class,  which  is 
represented  by  the  V'iew's  Delta,  attribute.  The  Modifier  Is  used  to  manipulate 
the  View’s  position  and  direction  relative  to  its  Attachable_Player,  and  the 
Modifier  contains  coordinate  attributes,  called  State,  accordingly.  Like  the 
Terrain  and  Player,  the  Modifier  class  defines  an  abstract  component  with 
connectors  that  must  be  proNlded  in  its  subclasses.  Examples  of  Modifier  sub¬ 
classes  used  in  ObjectSim  applications  are  the  mouse,  keyboard,  spaceball,  and 
head  mounted  display.  The  main  operation  of  the  Modifier  class  is  called  poll, 
and  subclasses  must  override  this  operation  to  define  how  the  device  receives 
input  data  every  frame  of  the  simidation.  The  Modifier  class  also  provides  a 
reset  operation  and  two  Initialization  operations,  inii_state  and  init.  Figure  20 
displays  the  Rumbaugh  diagram  representing  the  Modifier  class. 

Easy_Sim  does  not  follow  the  ObjectSim  design  for  its  View  class.  To  be 
consistent  with  its  Model  and  Player  classes.  Easy_Sira  defines  the  class  to  man¬ 
age  a  single  View,  pushing  multiple  View  administration  to  the  View^Manager 
class  as  described  in  the  next  seaion.  As  attributes,  the  Easy_Slm  View  class 
incorporates  the  Player  to  which  the  View  is  attached,  the  optional  Modifier, 
and  the  Coords  eliminated  prexiously  by  the  loss  of  the  Attachable_Playcr 
class.  Additionally,  the  View  contains  a  Channel  and  Scene.  These  attributes 
allow  simulations  with  multiple  Views  to  display  distina  collections  of  entities 
In  each  of  its  windows. 


Figure  19.  View  Class  Objea  Model  Diagrams 


The  Easy_Sim  V'ievv  class  provides  operadons  equivalent  to  those  present 
in  ObjectSim,  but  secvjew  is  renamed  Update,  alloc_shared  and  new_view  are 
done  by  Initialize  and  Configure,  and  attach_to_player  is  a  simple  attribute  Set 
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operation.  Figure  19  shows  the  Easy_Sim  design  of  the  View  classes.  .A5  with 
the  Easy_Sim  Player  diagram,  the  Get  and  Set  operations  on  the  Coords  attribute 
are  not  shown,  and  a  full  listing  can  be  found  with  the  Modifier  in  Figure  20. 


ObJectSim 


LEGEND; 

^  Inherits 


Easy«.Slm 


Ho(3ifi«r  (abstract) 
Coords 


Zaitlalizs 

PlDallzo 

Dpdata  (abstract) 

a*sat 

Sat_Coord8 

Sat_PoBition 

Sat_X_PoBition 

Sot_y_Position 

Sot_Z_PoBltlon 

Sat_Diractlon 

Sat.Hsadinp 

Sat_Pltcb 

Sot.Roll 

Coords 

Position 

z_Posltion 

y^Positlon 

apposition 

Piroction 

Kaading 

Pitch 

RolX 

StandardpZnput 

Mousa 

Evant 

Znitializa 

Dpdata 


Figure  20.  Modifier  Class  Object  Model  Diagrams 


70 


Easy_Sim  reuses  the  clean  design  of  the  abstract  Modifier  class,  but  re¬ 
names  the  poll  operation,  observing  that  many  input  devices  use  queueing 
instead  of  polling  to  gather  data.  For  this  operation,  Easy.Sim  once  again  uses 
its  ubiquitous  name.  Update.  The  functionality  of  ObjectSira's  init^state,  init. 
and  reset  operations  are  migrated  to  Easy_Sim  by  the  Initialize  constructor  and 
Reset  operation.  The  Modifier  class  works  analogously  to  the  Environment 
class,  whereby  smaller  pieces  may  be  combined  in  an  aggregate  that  follows 
the  architectural  design  established  by  the  abstract  base  class.  Easy_Sim  pro¬ 
vides  a  default  Modifier  class,  Standard^Input,  that  accepts  input  from  a  mouse 
and  keyboard.  Figure  20  outlines  the  Easy_Sim  design  of  the  Modifier  classes. 

3.7  The  New  Manager  Classes 


AS  previously  mentioned,  the  Model,  Player,  and  View  classes  in  Easy_Sim  each 
form  an  abstraaion  representing  a  single  object.  However,  multiple  instances 
of  each  of  these  classes  are  necessary  to  achieve  a  viable  simulation.  Object- 
Sim  handles  these  multiple  instances  inconsistently  throughout  the  different 
classes,  as  the  Flt_Model  class  administers  numerous  objects,  but  the  Player  and 
View  classes  handle  only  one.  Easy_Sim  seeks  to  make  multiple  instance 
handling  more  architecturally  harmonious,  and  achieves  this  with  the  addi¬ 
tion  of  container  classes  to  manage  multiple  Models.  Players,  and  Views.  The 
Easy^Sim  architecture  benefits  from  the  addition  of  these  classes,  as  they  pro¬ 
vide  customization  points  for  application  developers  that  are  not  available  in 
ObjectSim. 

The  Model^Manager  class  provides  an  architectural  vehicle  for  con¬ 
trolling  the  various  Model  classes  that  represent  entities  in  the  simulation. 
This  manager  class  defines  a  simple  default  operation,  Assign^Mode!,  which 
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determines  whether  a  Model  already  exists  and  should  be  cloned  to  efficiently 
manage  memory’.  Figure  21  contains  a  Rumbaugh  diagram  of  the  Easy_Sim 
ModeLManager  class. 

This  simple  default  design  of  the  ModeLManager  should  suffice  for  most 
applications,  but  others  may  wish  to  customize  how  the  Models  in  the  Simula- 
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tion  are  manipulated,  fs.  ModeLManager  .sybclass  may  wish  to  define  different 
techniques  for  level  of  detail  control  or  for  compatibility  with  a  different  co¬ 
ordinate  system.  A  subclass  may  also  simply  require  ancth  avenue  for  as¬ 
signing  the  Models.  The  ability  to  easily  customize  the  control  over  Models  is 
not  present  in  ObjectSim,  so  the  addition  of  the  manager  class  into  the 
Easy_Sim  architecture  has  had  an  impact  on  the  overall  design  larger  than  the 
simple  addition  of  functionality'.  The  addition  of  this  class  has  created  the  po¬ 
tential  for  ilie  addition  of  many  functions  by  supplying  a  common  architec¬ 
tural  component  and  standard  connectors  from  which  customization  can  read¬ 
ily  occur. 

The  Player^Manager  class  also  provides  a  simple  default  class,  and  it 
maintains  the  list  of  Players  that  Interact  in  the  simulation.  Its  operations  in¬ 
clude  Add,  which  places  a  new  Player  into  the  list,  and  Update,  which  simply 
calls  the  Update  for  each  Player  in  the  list.  Figure  21  also  shows  the  Rum- 
baugh  diagram  representing  the  Player_Manager  class. 

The  Player_Manager  class  also  forms  the  architectural  entry  point  for  a 
limitless  number  of  customizations  for  Easy_Sim  applications.  The  default  class 
provides  no  real  organization  of  the  Players,  but  different  subclasses  could 
Institute  methods  for  optimizing  rendering  by  spatially  organizing  the  Players 
lHar94,130].  An  application  could  also  add  collision  deteamn  into  Easy^Sim 
applications  through  the  Player_Manager.  Most  importantly  ^or  the  AFIT 
Graphics  Lab,  the  Player_Manager  class  provides  a  sound  starting  point  for 
bringing  network  player  managers  into  the  architecture:  Ide..'\lly,  an  abstract 
class  could  be  designed  that  is  general  enough  for  any  distributed  interactive 
simulation.  Subclasses  could  be  derived  for  each  particular  application,  cus- 
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lomizing  Its  specific  needs  according  to  a  standard,  undcrsTanHa.hip  prrhitcr- 
tural  plan. 

Like  the  other  manager  classes,  (he  View_M,inagcr  class  niaintains  a  list 
allowing  a  simulation  to  have  multiple  Views.  The  View.Manager  class  also 
Stores  a  list  of  View  states,  each  of  which  describes  a  Player  and  the  relative- 
offset  of  the  last  View  attached  to  that  Player.  .Administering  a  list  of  \'icw 
states  allows  a  View  to  attach  to  one  Player  at  a  particular  offset  for  some  time 
period,  then  ati.ich  to  a  different  Player  for  another  time  period,  and  then 
eventually  reattach  to  the  first  Plaser,  remembering  the  previous  offset  and 
orientation.  This  feature  works  more  easily  in  ObjectSim  due  to  each  .Vtach- 
ab!e_Player  storing  its  own  state,  but  the  elimination  of  the  Attachable_Player 
class  to  maintain  a  pure  design  (sec  Section  -1.5)  forces  Eas\_Sim  to  develop  this 
alternate  solution. 

The  View_Managcr  class  provides  some  basic  operations.  Add  places  a 
new  View  into  the  list,  5er_V'jt*iv  activates  a  View,  Set^^PIayer  switches  the 
Player  to  which  a  View  is  attached,  and  Update  calls  the  Update  operations  for 
all  active  Views  View  state  management  is  iindertaVen  In  the  Sef_P)3ycr  op¬ 
eration.  Figure  2i  shows  a  Rumbaugh  diagram  of  the  Vicw_Manager  class. 

Like  the  other  manager  classes,  Easy.Sim's  V’icw_Manager  class  pro- 
vide.s  default  functionality,  fully  e.xpccilng  that  applications  win.  customize 
their  View  management  by  Inheriting  from  the  component  and  connector 
protocols  established  by  this  class.  Window  management  will  probably  be  the 
most  widely  used  reason  for  tailoring  the  Vle'.v_Mar.ager  class,  in  applications, 
as  each  View  has  Its  own  window  In  the  display.  The  View_Manager  class  will 
also  administer  input  device  handling,  because  user  input  is  commonly  ob¬ 
tained  from  windows  through  the  operating  sy.st£m. 
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3.8  The  Pfmr.Renderer  and  Simulation  Gasses 


The  main  purpose  oi  the  ObjectSim  Simulation  class  is  to  glue  together  all  of 
the  other  pieces  within  the  simulation.  Like  many  other  classes,  the  Simula¬ 
tion  class  is  abstract,  and  prescribes  a  component  and  its  connectors  within 
the  architecture.  Its  attributes  consist  of  Terrain  and  Pfmr_Renderer  objects. 
In  order  to  fully  understand  the  Simulation  class,  the  Pfmr.Rcnderer  class 
must  also  be  examined. 

Just  as  ObjectSim  prefaced  the  name  of  Its  Flt.Model  class  to  indicate  its 
dependence  on  a  particular  software  package,  the  Pfmr_Rendercr  class  is 
named  to  show  its  reliance  on  the  Performer  library’.  Originally  this  class  was 
designed  to  collect  all  of  a  simulation's  Performer  dcperdencies  in  one  module, 
so  that  ObjectSim  would  be  more  portable  [Sny94].  While  this  concept  is  com¬ 
mendable,  it  was  never  realized,  as  all  of  the  ObjectSim  classes  are  dependent 
on  Performer  in  varying  degrees.  Resides  isolating  dependencies,  the 
Pfmr_Rendercr  class  maintains  lists  of  Players  and  Views,  and  effectively  only 
provides  the  functionality  for  drawing  the  simulation.  In  other  words,  the 
pfmr.Rcnderer  class  is  functionally  oriented,  and  the  operations  that  (t  de¬ 
fines  operate  on  attributes  which  should  belong  to  the  Simulation  class.  This 
anomaly  is  evident  from  the  discussion  of  the  design  of  the  ObjectSim  Simula¬ 
tion  class,  which  explains  that  the  Sirnulaiior:  performs  state  transitions  de¬ 
pending  on  Pfmr_Rendorcr  operations  tSny93,Flgl4).  Finally,  the 
Pfmr.Renderer  class  contains  a  Performer  related  attribute,  p/pe,which  stores 
a  representation  of  the  processors  on  which  Performer  executes  Its  applica¬ 
tion.  cull,  and  draw  threads  (see  Section  2.4). 

The  Easy.Sim  software  architecture  defines  an  abstract  Simulation  class 
by  combining  ObjectSim's  Pfmrjtenderer  and  Simulation  classes.  The  elimi- 
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nation  of  Pfmr_Rendsrer  prcscp/es  the  integrity  of  the  object-oriented  data 
abstraction  architectural  style  employed  by  Easy_Sim.  Like  Its  namesake  in 
ObjectSim,  the  Simulation  class  in  Easy_Sim  serves  as  the  glue  that  holds  the 


other  pieces  of  the  application  together.  The  operations  of  the  Easy_Sini  Simu¬ 
lation  class  arc  drawn  from  its  two  predecessors. 

The  ObjectSim  Simulation  class  has  one  main  operation,  propagnic.  This 
operation  is  abstract,  and  must  be  overridden  by  a  subclas.s  to  upuate  each 
frame  of  the  simulation.  The  Simulation  class  also  provides  two  separate  ini¬ 
tialization  operations,  slloc^shsred  and  in/r_s/m.  Operations  in  the 
Pfur.Renderer  class  include  render,  which  is  the  continuous  loop  that  directs 
the  entire  simulation,  arbitrate,  which  opens  screen  windows  and  establishes 
callback  operations  for  the  customization  of  Performer's  cull  and  draw 
threads,  and  insertmodel,  which  ;  dds  an  entity  to  the  simulation.  ObjectSim’s 
Pfmr.Renderer  and  Simulation  cla-.  -s  are  repre.senied  by  the  P.umbaugh  dia¬ 
grams  in  Figure  22. 

Easy_Sim's  Simulation  class  has  attributes  for  a  Performer  Pipe,  an  En¬ 
vironment,  a  Player.Managcr,  a  .ModeL.^lanager,  and  a  Yie'.v_Manager.  and  it 
builds  these  data  struaurcs  by  means  of  three  overloaded  Add  operations.  The 
first  of  these  operations  adds  an  Environment  and  its  Model  into  the  Simulation 
for  a  given  View.  The  second  adds  a  View  al'  “tg  with  its  Modifier,  its  attached 
Player  and  Its  offset  from  the  Player,  into  the  View_Manager.  The  final  Add 
operation  stores  a  Player  with  Its  Model  and  Its  Coords  in  the  Player_Manager 
for  a  given  View.  Each  Add  which  deals  with  a  Model  also  assigns  that  Model 
using  the  ModcLManager. 


In  addition  to  the  Add  operations:  the  Simulation  class  also  provides 
constructors,  an  Open-Window  operation,  a  A’ender  operation,  and  an  abstract 
Updste  operation.  These  operations  correspond  to  the  aliOC_shared  and 
init»sim.  arbitrate,  render,  and  propagate  operations  in  ObiectSim.  Some  of  the 
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Figure  22.  Simulation  Class  Object  Mode'.  Diagrams 


functionality  assigned  to  the  Pftnr_Renderer  operations,  such  as  multiple 
Player  and  View  management,  are  moved  to  Easy_Sim’s  manager  classes. 
Easy_Sim  supplies  an  abstract  Applicstson^Namc  operation,  so  that  application 
developers  can  customize  the  title  of  their  simulation  windows.  Figure  22 
shows  a  Rumbaugh  diagram  of  the  Easy_Sim  Simulation  class. 

3.9  Summary'  of  Easy_Sim  Design 


Figure  23  shows  a  Rumbaugh  diagram  outlining  the  relationships  among  the 
classes  In  the  Easy_Slm  architecture.  To  summarize  the  discussion  In  this 
chapter,  the  Model  class  stores  database  information  describing  how  an  object 
appears  graphically,  and  this  funaionality  is  used  by  the  Environment,  which 
serves  as  the  visual  background  for  the  application.  The  Model  class  may  also 
represent  Players,  which  arc  the  entities  whose  Interaction  defines  the  appli¬ 
cation.  A  single  Model  may  be  cloned  to  represent  multiple  Players  of  the  same 
type.  The  application  is  seen  through  Views,  which  must  be  attached  to  a 
Player,  and  may  be  changed  by  a  Modifier.  A  Simulation  ties  the  application 
together  and  encompasses  the  Environment  along  with  manager  classes,  each 
of  which  administers  multiple  copies  of  their  respective  namesake  classes. 
The  diagram  Implies  that  the  Simulation  class  h  as  knowledge  of  tuS  Model, 
Player,  and  View  classes. 

Figure  24  shows  the  language  independent  architectural  model  for 
Easy_Sim.  Easy.Sim  retains  the  architectural  style  of  ObjectSim  as  a  layered, 
heterogeneous  system  (see  Section  2.2).  The  Easy_Sim  layer  follows  the  object- 
oriented  data  abstraction  style,  and  defines  the  basis  for  components  and  their 
connectors  in  an  application.  Under  the  Easy.Sim  layer  sits  the  Performer 
layer,  which  is  a  case  of  the  pipe  and  filler  model.  Ax  the  core  of  the  Easy_Sim 
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architecture  lie  the  GL  rendering  Iibrar>’  and  the  IRIX  operating  system,  but 


they  exist  at  a  low  level  of  sbstrsctioii  and  are  generally  omitted  from  discus* 
Sion  through  jut  this  thesis.  A  developer  builds  an  application  on  lop  of  this 
structure,  mainly  interacting  with  Easy.Sim.  Because  the  lower  libraries 
provide  powerful  capabilities,  the  srchitecture  retains  the  ability  for  the  de* 
veloper  to  access  them  directly. 

Ideally,  the  Easy_Sim  architecture  should  be  portable,  and  its  underly¬ 
ing  layers  should  be  interchangeable  with  a  graphics  library  from  any  plat¬ 
form.  There  Is  nothing  inherent  in  the  Easy_Sim  architectural  design  that 
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prevents  this  adaptation,  but  no  industr\'  standards  for  graphics  libraries  cur¬ 
rently  exist.  The  architectural  connectors  that  allow  Interaction  between  the 


Easj-_Sim  and  Performer  layers  therefore  operate  differently  than  connectors 
to  other  commercial  graphics  libraries  would  operate.  Ea.sy_Sim  attempts  to 
minimize  the  points  where  any  modification  would  be  necessary',  but  evalua¬ 
tion  of  these  attempts  cannot  be  quantified  objectively  without  attempting  to 
migrate  an  implementation. 

This  chapter  has  discussed  the  architectural  design  issues  involved  in 
migrating  from  ObjeaSim  to  Easy_Sim.  The  next  chapter  examines  the  imple¬ 
mentation  issues  involved  in  the  transition.  Ada  9X  solutions  are  shown  that 
realize  the  Easy_Sim  application  framework. 
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IV  Application  Framework  Implementation 

This  chapter  examines  the  implementation  phase  of  this  thesis  effort.  It  de¬ 
scribes  the  transformation  of  the  architectural  design  explained  last  chapter 
Into  the  Easy_Sim  application  framework.  This  chapter  describes  the  Ada  9X 
version  of  Easy_Sim,  but  a  corresponding  0+4  version  was  also  developed,  so 
that  a  fair  performance  comparison  could  be  made.  The  differences  between 
these  two  versions  are  described  In  Section  6.3. 

The  discussion  first  covers  general  concepts  that  relate  to  the  imple¬ 
mentation  effort.  These  topics  include  the  ObjectSim  framework,  strategies  for 
migrating  ObjectSim  to  Easy.Sim,  the  framework’s  dependence  on  Performer, 
and  the  maturity  of  Ada  9X  compilers.  The  chapter  then  presents  the  code 
template  that  Easy^Sim  uses  as  the  basis  for  each  of  its  classes.  The  final  por¬ 
tions  of  the  chapter  highlights  the  implementation  issues  specific  to  each 
Easy.Sim  class.  The  details  of  the  implementation  can  be  found  in  the  headers 
of  the  Easy_Sim  code,  which  can  be  obtained  by  following  the  directions  at  the 
end  of  this  document  in  Section  7.3. 

4.1  General  Issues 


This  section  ser\'es  as  a  preface  to  discussing  the  implementation  of  Easy.Slm. 
It  presents  the  underlying  decisions  that  were  made  to  form  the  general  strat¬ 
egy  for  the  production  of  the  code.  It  first  examines  the  ObjectSim  application 
framework  and  describes  the  ideas  considered  for  migrating  this  code  to  Ada 
9X.  This  section  also  addresses  Easy_Sim's  dependencies  on  the  Silicon  Graph¬ 
ics  Performer  library  and  the  GNAT  compiler. 


4.1.1  ObjectSim  Implenjer.taticn 


Chapter  III  described  the  necessity  model  that  Mark  Snyder  used  to  develop 
ObjectSim,  and  discussed  how  the  code  produced  by  the  Scven  Graphics  Lab  stu¬ 
dents  innuenced  ObjectSim’s  structure,  vvhile  the  necessity  model  allowed 
great  gains  in  the  Lab's  productivity,  it  had  negative  effects  on  both  the  Ob¬ 
jectSim  design  and  implementation.  Snyder  states  in  his  thesis,  "For  each  new 
problem  solved,  the  major  challenge  was  to  fit  it  into  the  architecture  while 
preserving  a  good  design  and  not  perturbing  the  existing  code  too  much" 
[Sny93.72J.  This  section  addresses  the  consequences  of  this  approach. 

Because  the  C+-  language  used  to  develop  the  ObjectSim  framework  was 
new  to  each  of  its  contributors  (Sny94],  many  of  its  positive  features  were  not 
exploited.  The  encapsulation  mechanism  in  Cf  4  provides  public,  protected,  and 
private  sections  in  a  class,  and  is  used  to  prevent  global  maulpulatlon  of  mem¬ 
ber  data.  ObjectSim  makes  free  use  of  global  access,  however,  as  class  members 
are  generally  public  and  modified  by  other  classes.  This  lack  of  encapsulation 
results  in  ObjectSlm's  classes  havin  g  low  cohesion  and  high  coupling,  and 
causes  logically  abstruse  code  with  untraceable  effeas.  In  addition  to  neglect¬ 
ing  C4+'s  encapsulation  mechanisms,  ObjectSim  also  avoids  constructors  when 
initializing  Us  classes.  The  omission  of  this  basic  C-4  feature  is  rather  cumous, 
and  results  in  the  u  ;e  of  inconsistent  initialization  operations  throughout  the 
framework. 


ObjectSim  is  further  complicated  by  Che  contribution  of  code  from  seven 
individual  developers.  First,  the  differing  styles,  naming  conventions,  depth 
of  comments,  and  coding  Idioms  make  various  portions  of  the  framework  in¬ 
consistent  and  hamper  Us  understandability.  Second,  the  rapidity  with  which 
code  contributions  were  integrated  often  results  in  a  lack  of  proper  documen- 
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tation.  Portions  of  the  ObjectSim.  code  remain  a  complete  mystery'.  The  lack  of 
encapsulation  further  exacerbates  this  matter,  as  an  attempt  to  modify  code  in 
one  class  often  causes  unexpected  behavioral  changes  in  another  class. 

The  next  section  describes  how  the  negative  aspects  of  the  ObjectSim 
application  framework  affeas  the  development  of  the  Easy_Sim  framework. 

4.1.2  Easy_Sim  Migration  Strategies 


Originally  Easy_Sim  was  envisioned  as  an  extension  of  ObjeaSim,  with  the  in¬ 
tent  of  exploiting  reuse  where  possible.  Because  ObjectSim  has  proven  such  a 
success,  its  code  was  assumed  to  be  a  viable  starting  point  for  the  production  of 
Easy_Sim's  code.  Hotvever,  the  discovery'  of  the  problems  described  above 
caused  contingency  plans  to  be  evaluated  and  executed. 

Interaction  with  any  foreign  language  from  .Ada  presupposes  a  method 
of  conversing  with  that  language.  This  feat  is  accomplished  by  using  a  set  of 
bindings.  These  Ada  packages  are  filled  with  interface  pragmas  that  tell  an 
Ada  compiler  how  to  translate  Ada  entities  to  the  foreign  language.  The  Ada 
linker  can  then  interact  with  the  foreign  object  code  arid  incorporate  it  into 
the  Ada  executable  file.  Two  categories  of  bindings  exist.  A  thin  binding  con¬ 
tains  straight  Interfaces  to  the  foreign  language,  and  makes  the  caller  trans¬ 
late  complex  parameters  so  that  they  are  compatible  with  the  foreign  lan¬ 
guage's  method  for  storing  data.  A  thick  binding  is  more  robust  and  easier  to 


use.  Instead  of  simply  providing  interfaces,  a  thick  binding  provides  subpro¬ 


grams  which  convert  Ada  parameter  values  to  the  correct  format  and  then  call 


the  appropriate  operation.  All  of  the  migration  strategies  for  the  Ea.sy_Slm 
application  framework  use  some  form  of  bindings. 
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The  first  and  perhaps  most  grandiose  strategy  considered  for  imple¬ 
menting  Easy_Sim  took  reuse  to  the  extreme.  By  convincing  the  compiler  to 
derive  Ada  lagged  t^pes  from  C++  classes.  Easy_Sim  would  act  as  a  binding  to 
the  already  proven  Object.Slm  framework.  This  idea  '^vas  eliminated,  however, 
because  the  design  ObjectSim  classes  were  deemed  incompatible  with  the 
highly  cohesive  and  encapsulated  design  envisioned  for  Easy_Sim.  (Since  the 
dismissal  of  this  strategy,  Thomas  Quiggle  of  Silicon  Graphics  and  Dr.  Cyrilie 
Comar  of  the  GN.AT  Team  have  successfully  demonstrated  this  technology 
{Qul94b].  It  Is  unknown,  however,  if  their  solution  can  derive  from  C-r+  classes 
with  the  low  cohesion  of  the  ObjectSim  classes.) 

The  second  strategy  considered  for  the  implementation  of  Easy_Sim  also 
reused  the  existing  ObjectSim  code.  Although  derivation  from  the  abstract  C'r+ 
classes  had  been  discarded,  reusing  the  concrete  classes  was  examined.  This 
strategy  would  build  individual  bindings  to  each  of  the  member  functions  of 
each  concrete  C++  class,  and  would  treat  them  as  if  they  were  regular  C  func¬ 
tions.  This  approach  requires  an  additional  step  in  designing  the  bindings,  as 
the  implicit  C-+  class  pointer,  this,  must  be  passed  e.xplicitly  in  Ada  (Oui94a]. 
This  technique  is  further  complicated  if  the  C-r-r  member  function  accesses 
variables  outside  its  scope.  Unfortunately,  ObjectSim’s  reliance  on  global  ac¬ 
cess  caused  the  dismissal  of  tMs  strategy. 

The  most  practical  strategy  for  the  Easy^Sim  development  was  also  the 
most  obvious  strategy,  and  the  Easy_Sim  layer  of  the  application  framework  is 
written  entirely  in  Ada  9X.  Although  a  mapping  ber.vesn  an  encapsulated  C+- 
class  and  an  Ada  class  package  Is  straightforward,  the  low  cohesion  of  the  Ob- 
jertSlm  classes  confounds  the  process.  The  fmal  strategy  adopted  by  Easy.Slm, 
therefore,  Implements  its  classes  by  using  the  Object.'Jim  classes  solely  as  a  rcf- 
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erence  base.  Easy_Sim  does  not  attempt  tc  directly  translate  ObjectSim  and 
omits  some  of  the  most  complex  functionality  contained  in  its  predecessor. 
Easy_Sim  instead  concentrates  more  effort  on  the  architectural  design  and 
only  provides  the  basic  functionality  needed  to  produce  visual  simulations. 

4.1.3  Performer  Dependencies 


Although  the  final  migration  strategy  chosen  eliminates  the  need  to  interface 
with  C+-+,  it  maintains  interfaces  to  the  C-based  Silicon  Graphics  Performer  and 
GL  libraries.  Performer  manages  all  multiprocessing  and  drawing  an  applica¬ 
tion  undertakes  by  efficiently  processing  complicated  data  structures  every 
frame  of  the  simulation.  The  efficient  rendering  of  the  models  managed  by 
Performer  is  accomplished  by  GL  at  a  lower  level.  In  order  to  reap  the  tremen¬ 
dous  benefits  offered  by  these  libraries  and  achieve  acceptable  performance 
for  realistic  applications,  Easy.Sim  must  rely  upon  both  the  Performer  and  GL 
libraries. 


As  both  of  these  Silicon  Graphics  libraries  are  extensive,  creating  bind¬ 
ings  to  interact  with  them  is  a  complicated  undertaking.  Luckily,  developers 
at  Silicon  Graphics  have  built  bindings  to  both  libraries  in  order  to  produce 
their  Paintball  demonstration  program  IEmb94j,  and  they  have  been  gracious 
enough  to  contribute  their  work  to  this  research  effort.  Because  GL  is  older 
than  Performer,  its  binding  has  evolved  and  become  thick.  The  Performer 
binding  is  still  in  its  infancy  and  is  therefore  thin.  Easy_Sim  makes  many 
additions  to  the  Performer  binding,  in  fact,  because  the  binding  did  not  define 
interfaces  to  many  of  the  Performer  function  calls  used  by  Easy_Sim. 

Completely  freeing  the  Easy_Sim  application  framework  from  its  Silicon 
Graphics  based  environment  Is  necessary  to  make  the  application  framework 
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fully  portable,  but  this  division  is  beyond  the  scope  of  this  research  effort. 
Additionally,  in  order  to  achieve  a  fair  performance  comparison  with  an  Ob- 
jeciSim  implementation,  an  Easy_Sira  implementation  must  use  the  same  un¬ 
derlying  architecture. 

However,  because  portability  is  a  long-range  goal  of  Easy_Sim,  Per¬ 
former  dependencies  are  isolated  wherever  possible.  The  first  step  in  this 
process  is  to  ensure  that  an  application  developed  using  EasjLSIm  is  not  forced 
to  access  Performer.  The  second  step  is  to  push  the  Performer  dependencies  to 
the  bodies  of  components,  using  Ada  subunits  where  appropriate.  This  ap¬ 
proach  allows  a  new  body  to  be  written  using  a  different  graphics  library, 
changing  the  Implementation  without  affecting  the  Interface  and  therefore 
saNlng  expensive  recompilations. 

Eas>’_Sim  has  allowed  its  application  developers  to  lessen  their  depen¬ 
dency  on  Performer  and  GL.  and  the  example  program,  described  in  Section  .5.1 
Is  testament  to  this  independence.  However,  most  developers  realistically  will 
want  to  access  Performer  and  GL  to  benefit  from  their  extensive  capabilities. 
The  second  isolation  step  has  been  realized  for  GL,  as  Eas)'_Sim  only  calls  its 
routines  when  opening  the  simulation  window.  This  dependency  is  placed  in  a 
separate  subunit,  and  the  procedure  can  therefore  be  replaced  easily. 

While  the  vist  majority  of  Easy^Sim's  Performer  dependencies  have 
been  placed  in  package  bodies,  some  still  remain  as  attribute  and  parameter 
types  in  package  specifications.  Theoretically,  the  Performer  entitles  can  be 
renamed  or  subtyped  in  one  centralized  location  so  that  Easy.Sim’s  SGI  re¬ 
liance  is  obscure  throughout  the  rest  of  the  framework.  Easy_Sim  has  proven 
this  approach  by  subtyping  Performer’s  coordinate  types.  This  step  has  not 
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been  taken  for  every  Performer  type,  however,  and  il  is  left  for  future  re¬ 
searchers. 

Before  analysis  of  the  implementation  strategy  is  described  in  full,  the 
next  section  covers  topics  relating  to  the  compilation  system  used  to  implement 
the  Easy_Sim  application  framework, 


4.1.4  Compiler  Issues 


Just  as  Eas3'_Sim's  implementation  in  the  SGI  environment  depends  upon 
bindings  to  SGI  libraries,  it  is  also  reliant  on  the  existence  of  an  Ada  9X  com¬ 
piler  for  SGI's  IRIX  5.2  operating  system.  A  team  at  New  York  University  (NW) 
has  been  sponsored  bj’  the  Ada  Joint  Program  Office  to  develop  an  .Ada  QX 
compiler  under  GNU  Public  License  for  both  Sun  SPARC  and  IBM  OS/2  systems. 
Their  product  is  called  the  GNU  hlYU  Ada  Translator  (GNAT),  and  it  is  widely 
available  on  the  Internet  even  though  il  is  Still  under  development.  GNA.T  has 
been  ported  to  run  on  many  operating  systems  other  than  those  for  which  it 
was  originally  targeted.  Luckily,  the  developers  at  Silicon  Graphics  have 
ported  G.NAT  to  IRIX  5.2  for  use  with  Paintball,  and  they  have  agreed  again  to 
contribute  their  work  to  this  thesis  effort. 

GNAT  Is  part  of  the  Free  Software  Foundation’s  gcc  compiler  family.  Gcc 
accepts  code  in  a  wide  variety  of  languages,  transforms  that  code  .vith  a  lan^ 
guage  specific  front  end,  ard  generates  executables  with  a  common  back  end. 
Use  of  this  common  back  end  makes  GNAT  quite  mature  for  its  age,  as  gcc  has 
been  continually  improved  over  the  last  decade.  Hotvever,  the  Ada  specific 
front  end  is  still  rather  Immature  and  has  plenty  of  room  for  growth. 

A  new  version  of  GNAT  is  released  roughly  once  a  month.  The  version 
of  Easj’_5im  baselined  for  this  thesis  is  compiled  under  GNAT  version  1.83.  uiv 
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fortunately,  this  version  does  not  fully  implement  everj'  Ada  9X  features  that 
Easy.Sim  attempts  to  use,  and  alternate  solutions  are  developed  in  these  infre¬ 
quent  cases.  Private  extensions  for  derived  tagged  types  is  the  most  imponant 
of  these  incomplete  features.  To  correct  this  problem,  the  type  extensions  used 
in  most  Easy_Slm  classes  remain  public.  Other  compiler  problems  include  the 
destructor  Finalize  not  being  called  automatically,  and  occasional  semantic 
confusion  when  a  nested  function  call  is  misinterpreted.  Neither  of  these 
cases  cause  much  trepidation,  thankfully,  as  Finalize  is  called  explicitly,  and 
the  data  obtained  with  function  calls  is  accessed  directly. 

GNAT  version  1.84  has  been  released  on  a  small  scale  since  the  baselin¬ 
ing  of  Eas3'_Slm,  and  the  arrival  of  Us  successor,  2.00.  is  due.  The  GNAT  devel¬ 
opment  team  has  addressed  the  problems  above,  as  they  use  Er  sy_Sim  as  one  of 
their  test  cases.  This  thesis  therefore  assumes  that  the  problems  mentioned 
above  have  been  rectified,  and  presents  the  implementation  of  Easy_Sim  as  if  a 
complete  Ada  9X  compiler  were  available. 

Discussion  now  concentrates  on  the  Easy_Sim  implementation,  starting 
with  the  package  that  sert^es  as  the  parent  for  the  Easy_Sim  framework. 

4.2  The  Easy_Sim  Parent  Package 


The  Easy_Sim  application  framework's  bmplementation  in  Ada  9X  employs  hi¬ 


erarchical  library  units  to  create  a  large,  logically  related  subsystem,  while 
maintaining  small,  physically  distinct  pieces.  This  notion  creates  a  cohesive 
and  understandable  hierarchy  that  remains  modular  and  manageable. 

At  the  root  of  this  subsystem  lies  the  Easy_Sim  package.  Nothing  needs 
to  be  placed  inside  this  package,  but  it  must  exist  to  serve  as  the  skeleton  that 
provides  the  basic  structure  for  the  rest  of  the  hierarchy.  For  convenience, 
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entities  commonly  used  throughout  the  Easy_Sjm  framework  are  placed  within 
the  parent  package,  because  all  declarations  in  the  parent  are  visible  to  any 
child  units.  The  coordinate  types  from  Performer  are  subtyped  here,  because 
they  are  used  by  many  different  classes.  An  operation  to  read  coordinates 
from  a  file,  Read_Coords,  is  also  localized  with  the  type  on  which  it  operates. 
The  context  clauses  for  packages  accessed  throughout  the  framework  are  de¬ 
clared  ahead  of  Easy_Sim.  These  clauses  include  the  Performer  bindings  and 
Ada.Finalization,  which  declares  the  root  types  for  controlled  types. 

Before  analysis  of  each  class  in  the  Easy_Sim  application  framework  oc¬ 
curs,  the  next  section  describes  the  commonalities  that  exist  in  each  class. 

4.3  Easy_Sim  Class  Package  Conventions 

Because  the  classes  In  Easy_Sim  use  the  ROMAN’-9X  technique  for  their  Ada  9X 
implementation,  they  each  share  CO. codii^^  id  10 ! i.s , 
and  a  general  structure  (see  Sections  2.1.4  and  3.2).  This  section  presents  the 
code  that  all  classes  have  in  common,  so  that  is  not  repeated  throughout  the 
discussion.  It  also  addresses  the  additions  to  ROM.^N-9X  that  were  added  espe¬ 
cially  for  Easy_Slm.  . 

Figure  25  contains  the  general  outline  of  the  code  used  to  a  class  in  the 
Easy_Sim  application  framework.  A  hierarchical  library  unit  encapsulates 
each  class,  and  this  package  is  a  child  of  the  framework  encompassing  pack¬ 
age,  Easy_Sim.  The  class  is  defined  as  a  controlled  tagged  type  called  Object, 
and  may  be  abstract.  New  attributes  used  to  extend  this  type  are  declared  in 
the  private  part.  Each  class  provides  a  classwide  access  type,  and  this  type  is 
called  Reference.  Controlled  operations  are  declared,  and  a  parameterized  ini¬ 
tialization  operation.  Configure,  is  also  supplied.  The  parameters  to  Configure 
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are  often  given  default  values,  so  that  they  only  need  be  addressed  in  unique 
cases.  The  class  package  then  declares  Its  main  operations,  which  usually  in¬ 
clude  Update  and  Draw,  and  they  may  be  abstract  or  provide  default  behavior. 
The  Set  procedures  and  Get  functions  are  then  declared  for  the  anributes  for 
which  they  are  needed.  The  Set  procedures  are  named  eitplicitly  Set_(Attri- 
bute),  while  the  Get  functions  are  named  by  the  attribute  they  return.  Because 
the  Get  and  Set  subprograms  are  usually  simple,  Inline  is  applied  to 

them  to  optimize  the  code's  execution  time.  In  the  actual  type  extension, 
attributes  that  are  instances  of  another  class  are  stored  as  Other_Class.Ref¬ 


erence.  This  indlreaion  is  necessary  so  that  the  attribute  can  be  passed  to  and 
from  class  operations,  including  the  simple  Get  and  Set  operations,  without 
violating  the  one  tagged  subtype  per  operation  rule  [RM94,  3.9.2.12].  The  use 
of  a  pointer  also  more  closely  models  a  real  world  situation,  where  only  one 
copy  of  each  entity  exists. 

Two  categories  of  Easy^im  classes  are  declared  at  another  level  of  depth 
within  the  Easy.Sim  framework.  The  manager  classes  exist  as  hierarchical  li¬ 
brary'  units  within  the  class  they  manage.  The  Player_Manager  class  package! 
for  example,  is  declared  as  Easy_Sim.Player.Manager,  logically  adding  a  Man¬ 
ager  child  package  to  the  Easy_Sim. Player  package.  This  technique  of  embed¬ 
ding  packages  is  also  used  for  the  default  iir.plemeniatlons  of  the  classes  such 
as  Easy_Sim.Envlronment.Terraln  and  Easy_Sim.Modlfier.Standard_Input  that 
are  provided  for  applications  developers. 


with  Easy_sir..0ther_Clas6; 
packaga  Easy_Siin. Class  la 


typa  Obiect  ia  abstract  naw  Ada. Finalization. Controlled  with 
prlvata ; 

typa  Reference  Is  access  all  Object 'Class; 


procedure 

Initialize 

(Instance 

:  in 

out 

Cbject) ; 

procedure 

Adjust 

(Instance 

;  in 

out 

Cbjcct) ; 

procedure 

Finalize 

(Instance 

:  in 

cut 

Object) ; 

procedure 

Cor.f  ig--r€ 

(Instance 

;  in 

out 

Object ; 

Parameter 

:  in 

?arameter_'ri'pe  :=  0; 

procedure 

Update 

(Instance 

:  ia 

out 

Object;  ia  abatract; 

procedure 

Draw 

(Instance 

:  in 

out 

Object)  is  abstract; 

procedure 

Operation 

(Instance 

:  in 

out 

Object ; 

Parameter 

:  in 

Parameter_Ti'pe  ) ; 

procedure  Set_AttribJte_A 

{Instance  :  in  out  Object; 

Tc_Attribute_A  ;  in  Attribute_‘ryp®I » 

procedure  Set_Attribute^B 

(Instance  i  in  out  Object; 

Tc_Attribute_3  ;  in  Easy_Siir..Cther_Class  .Ref crence) ; 

pragma  Inline  (Set_Attrib‘Jt6_A,  Sec_Attribute_B) ; 

function  AttribiJt€_A  (Instance  :  Object)  return  Attribute_7ype; 
function  Attrib-t6_B  (Instance  :  Object) 
return  Easy_Si!n.Other_Class. Reference; 
pragma  Inline  (Attribute_A,  Attribute_R| ; 

private 

type  Object  ia  abstract  new  Ada. Finalization. Controlled  with 
record 

Attributc_A  :  Attrlbute^Ij'pe  ;=  Attribute_Ir.iti6l_V£lue; 

Attribute_B  :  Easy_Sir\.Other_Class .Ref erence; 
end  record; 

end  Easy^Sirr.. Class; 

Figure  25.  General  Easy_Slir.  C)as.t  Format 


The  package  specification  in  Figure  25  represents  the  basis  for  all  of  the 
class  packages  corresponding  to  the  Easy_Slm  architectural  components.  The 
rest  of  the  chapter  describes  the  features  of  each  class  that  make  its 
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implementation  unique.  Discussion  starts  at  the  bottom  of  the  dependency 
chain,  and  progresses  until  the  Simulation  is  reached.  The  code  to  accompany 
this  discussion  is  not  included  in  the  text  due  to  its  length,  and  the  figures  in 
Chapter  III  can  help  the  reader  follow  discussion.  Section  7.3  describes 
methods  by  which  the  reader  can  obtain  a  copy  of  the  code. 

4.4  The  Model  Classes 

This  section  discusses  the  Model  and  Model_Manager  classes,  which  are  re¬ 
markable  because  of  their  simplicity.  The  power  of  Performer  accounts  for 
this  positive  property,  as  the  library'  supplies  most  of  the  functionality.  Mod¬ 
el's  Configure  operation,  for  instance,  turns  graphical  database  geometry  built 
from  many  different  tools  into  a  Performer  rendering  tree  node  with  one  call 
to  Performer's  LoadFile  function.  The  remainder  of  this  section  examines  the 
Adjust  operation  in  the  Mode!  class  and  briefly  describes  the  workings  of  the 
ModeLManager  class.  Figure  16  shows  the  Rumbaugh  diagram  of  the  Model 
class,  while  the  ModeLManager  can  be  found  in  Figure  2 1. 

The  Model  class  is  unique  among  the  Ea5y_Sim.  classes  because  it  is  the 
only  class  whose  Ada  type,  Object,  is  controlled,  instead  of  limited  controlled 
(see  Section  2.1.2).  This  trait  follows  from  the  need  to  copy  instances  of  the 
class  (see  Sealon  3.3),  which  does  not  exist  elsetvhere.  The  Mode!  class  pro¬ 
vides  both  a  procedure  and  function  to  Clone  Models,  and  both  of  these  rely  on 
the  controlled  .Adjust  procedure  and  a  Performer  Clone  function  to  accomplish 
their  objective.  The  Adjust  procedure,  however,  was  not  as  straightforward  to 
use  as  originally  envisioned.  Because  it  only  takes  one  Model.Object  parame¬ 
ter,  the  notion  of  source  and  target  for  assignment  inside  Adjust  becomes 
rather  clouded-the  parameter  must  serv^e  as  both.  The  scluiion  is  to  start  with 
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a  temporary  variable  as  Che  target  and  the  parameter  as  the  source.  Per¬ 
former's  Clone  function  is  called  on  the  parameter,  with  the  result  saved  to  the 
temporary  variable.  The  final  step  is  to  assign  the  temporaty  back  to  the  pa¬ 
rameter.  This  step  must  be  accomplished  using  the  record  components  of  the 
Model.Object,  as  assigning  the  .Model.Object  itself  will  result  in  infinite  recur¬ 
sion.  The  remainder  of  the  Model  class  is  implemented  in  a  straightforward 
manner. 

The  container  that  differentiates  Models,  the  Model.Manager  class,  uses 
the  file  name  containing  a  database  to  distinguish  various  Models.  It  stores  a 
list  of  these  file  names  and  their  accompanying  Models.  The  Assign.Mode! 
procedure  Is  given  a  string  parameter.  FJle^Nawe,  which  it  compares  against 
the  names  in  the  list  using  the  private  Index  funaion.  If  a  match  is  found,  the 
.Model  being  assigned  is  copied  from  the  Model  at  the  appropriate  Index  in  the 
list,  using  the  Model.Adjust  procedure.  If  no  match  is  found,  Model.Configure 
is  called  to  convert  File.Name  into  a  rendering  tree,  and  the  new  Model  and 
FlIe.Name  are  stored  in  the  list.  The  reader  should  note  that  if  two  distinct 
files  contain  the  same  Model,  the  Model.Manager  cannot  recognize  this  equal¬ 
ity.  The  developer  can  also  use  this  trait  if,  for  some  reason,  he  does  not  wish 
.Model  cloning  to  occur. 

The  next  section  examines  the  interesting  aspects  of  the  Environment 
class  and  Us  descendants. 

4.5  The  Environment  Classes 

This  section  analyzes  the  Environment  classes  in  the  Easy_Sim  application 
framework.  It  begins  with  the  abstract  base  class,  then  discussion  turns  to  the 
Horizon  and  Sun  building  blocks,  and  the  section  concludes  by  describing  the 
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default  Terrain  class.  Figure  17  shows  an  Object  Model  diagram  of  the  Envi¬ 
ronment  classes. 

The  abstract  Environment  class  works  quite  simply.  The  Initialize  Op¬ 
eration  allocates  the  Model  that  represents  the  simulation’s  background.  The 
Set_Model  procedure  is  used  to  assign  the  Model,  and  the  Image  function  re¬ 
turns  the  root  of  the  Model's  rendering  tree.  The  Configure  procedure  places 
the  Model's  local  tree  into  the  Simulation's  tree  by  using  a  Performer  cal!  to 
add  the  Model  to  the  tree  node  which  it  is  given  as  a  parameter.  This  technique 
is  used  throughout  the  Easy_Sim  classes,  in  fact,  wherever  a  Model  needs  to  be 
placed  In  the  Simulation's  rendering  tree.  The  only  other  operation  in  En'v"> 
ronment  is  the  abstract  Draw  procedure,  which  forces  a  subclass  to  declare  if  it 
intends  to  do  unique  rendering  on  the  draw  thread.  Examples  of  this  special 
drawing  includes  landscape  grids  or  text  overlays’. 

The  Terrain  class  is  derived  from  Environment  and  joins  the  basic 
functionality  of  the  Horizon  and  Sun  classes  to  model  the  eanh,  sky,  and  sun¬ 
light.  All  of  these  classes  were  based  on  the  ObjectSim  Simple^Terrain  class, 
but  modularizing  the  previously  monolithic  class  has  allowed  for  greater  pos¬ 
sibilities  of  future  reuse  at  both  the  design  and  coding  levels. 

The  Horizon  class  uses  the  basic  Performer  earth/sky  capabilities,  ESky. 
It  establishes  a  green  earth  and  a  blue  sky  that  gets  lighter  with  increasing 


altitude.  Its  values  are  hard  coded  and  taken  from  many  of  the  examples  pro¬ 
vided  with  Performer,  Performer  requires  the  Esky  to  be  attached  to  a  window, 
or  Performer  Channel,  as  it  does  many  items.  The  Configure  operation  awaits 
this  parameter  and  makes  the  proper  call  to  fasten  the  Esky  to  the  window. 
Performer  automatically  draws  the  Horizon  for  the  rest  of  the  simulation,  and 
no  Update  procedure  is  necessary  for  the  class. 
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The  Sun  works  similarly,  but  has  attributes  for  its  Position  and  Ambi¬ 
ence,  and  is  an  instance  of  the  Performer  LightSource  type.  Ambience  is  simi¬ 
lar  in  effect  to  brightness,  in  the  Initialize  constructor,  the  LightSource  is 
allocated,  the  Position  and  Ambience  are  given  default  values,  and  the  Sun  is 
set  to  shine  from  directly  overhead.  Performer  requires  a  LightSource  to  be 
included  in  the  rendering  tree,  and  the  Configure  operation  places  the  Sun  in 
the  tree  as  Environment.Configure  did  above.  Once  the  Sun  is  part  of  the  ren¬ 
dering  tree,  Performer  automatically  draws  it  everv'  frame  and  no  Update  pro¬ 
cedure  needs  to  be  provided. 

The  Terrain  class  brings  together  the  Environment.  Horizon,  and  Sun  in 
a  direct  manner  that  shows  the  benefits  of  the  building  block  approach.  The 
Terrain  class  has  both  Horizon.Reference  and  Sun.Reference  attributes.  Its 
Initialize  calls  its  parent's  Initialize  and  invokes  its  attributes*  Initializes  by 
allocating  them.  Terrain.Configure  likewise  calls  the  Configures  for  its  parent 
and  components.  Terrain  must  override  the  abstraa  Draw  procedure  it  inher¬ 
its  from  Environment,  and  it  makes  this  procedure  null.  Because  Performer 
handles  the  execution  of  its  attributes,  it  also  transitively  Updates  the  Terrain, 
and  after  initialization  is  complete,  there  is  nothing  more  to  do. 

This  section  has  described  the  ease  with  which  a  default  Environment 
can  be  created  due  to  the  building  block  approach.  The  next  section  high¬ 
lights  the  implementation  of  the  Player  and  Player.Manager  classes. 

4.6  The  Player  Classes 

This  section  examines  the  Interesting  aspects  of  the  Player  and 
Player_Manager  classes  of  the  Easy_Sim  application  framework.  The  Rum- 
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baugh  Object  Model  diagram  for  the  Player  class  is  found  in  Figure  1 S,  and  Fig¬ 
ure  2 1  shows  the  Player_Manager  class. 

The  abstract  Player  class  pro\ndes  the  basis  for  entities  within  the  simu¬ 
lation.  Its  controlled  Initialize  procedure  allocates  Its  .Mode!  attribute,  and  its 
Configure  procedure  adds  the  Model’s  geometry'  under  the  given  node  in  the 
rendering  tree.  Both  the  Move^Straight  and  Look_Ar  procedures  use  anal>'tic 
geometry  principles  to  calctilate  the  new  Position  and  Direction  of  the  Player. 
.An  instantiation  of  Ada  9X's  new  Ada.Numerics.Generic_Elementary_Functions 
package  is  used  in  Move_Straight  to  calculate  the  Sin  and  Cos. 

The  Player  class  provides  an  extensive  set  of  Cet  and  Set  operations  so 
the  client  programmer  can  gain  access  to  encapsulated  data.  The  Model  at¬ 
tribute  is  accessed  by  both  Image  and  Model  Get  functions,  with  the  Image  re¬ 
turning  the  rendering  subtree  for  that  Model.  The  Coords  attribute,  which 
contains  two  arrays  of  three  values  each,  ha.s  flexible  Get  and  Set  components 
which  return  world  coordinate  values  to  a  client  programmer.  These  opera¬ 
tions  include  Position,  X^Position,  Y.Position,  Z^Position,  Direction,  Heading, 
Pitch,  and  Roll,  in  addition  to  Coords.  This  final  operation  is  overloaded  and 
can  be  addressed  as  a  whole  or  as  a  Position  and  Direction  pair.  Because  the  Co¬ 
ords  operation  cannot  return  two  values,  the  Get  operation  for  the  second  Co¬ 
ords  is  a  procedure  called  Get^Coords.  Finally,  the  Player  class  provides  an  ab¬ 
stract  Update  procedure  through  which  a  client  programmer  must  define  the 
behavior  of  the  subclass. 

The  Pla3^er_Manager  class  provides  default  administration  of  the  Play¬ 
ers  who  interact  in  the  Simulation.  It  stores,  List,  an  array  of  the  Players  as 
well  as  the  Count  of  Players  in  List.  The  Update  procedure  simply  calls  Update 
for  each  of  the  Players  in  List.  The  Add  procedure  takes  in  a  Player  and  a  node 


96 


The  abstract  Modifier  class  is  intended  to  provide  the  means  through  which  a 


user  of  an  Easy_Sim  application  can  change  the  View.  Because 


tilL. 


does  not  have  access  to  the  View,  however,  it  simply  stores  Its  own  state  and 
lets  the  View  read  that  state  to  update  itself.  This  section  looks  at  both  the  ab¬ 
stract  base  class  and  the  Standard.Input  default  subclass.  Figure  20  shows  the 
Easy_Sim  Modifier  class  hierarchy. 

The  abstract  Modifier  class  contains  a  Coords  attribute  that  maintains 


the  offset  between  the  View  and  the  position  and  dirertion  to  which  the  user 
has  moved  and  pivoted.  The  .Modifier  therefore  has  a  slew  of  Get  and  Set  at¬ 
tributes  to  access  these  values.  Unlike  the  Player’s  global  coordinates,  the 
Modifier  class  maintains  local  coordinates,  in  that  its  Coords  are  an  offset  and 


pivot  relative  to  the  View.  The  Reset  procedure  sets  the  values  of  the  offset  and 
pivot  all  back  to  zero.  The  abstract  Update  procedure  is  the  conneaor  through 
which  subclasses  define  how  the  Coords  are  changed. 

The  Standard.Input  subclass  of  Modifier  provides  input  values  from  the 
mouse  and  keyboard,  and  is  only  partly  implemented.  The  package  maintains  a 
list  of  Boolean  flags,  each  of  which  represents  a  key  press  or  mouse  click 
during  a  frame.  The  flags  are  maintained  globally  in  the  package  specifica- 
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tion  so  that  client  packages  can  reset  them  after  their  use.  A  function.; 
Flag-Copy,  returns  a  pointer  to  the  structure,  and  it  is  the  preferred  method 
through  which  the  flags  are  accessed. 

The  Standardjnput  class  operates  by  means  of  Performer  utilities  that 
collect  input  from  the  mouse  and  keyboard  through  the  simulation  window. 
The  Initialize  constructor  initializes  both  the  Mouse  and  Keyboard  compo¬ 
nents,  and  the  Update  procedure  defers  to  R  and 

each  of  which  checks  the  queues  for  each  part  of  each  device  and  updates  the 
corresponding  input  flag  if  necessary.  The  Standard_lnDut  package  currentb' 
reads  data,  but  it  does  not  modify  its  inherited  Coords  attribute.  This  step  was 
the  next  addition  scheduled  for  the  Easy_Sim  framework  when  it  was  baselined 
for  this  thesis. 

The  Modifier  class  currently  Is  the  location  in  the  Easy.Sim  architec¬ 
ture  where  it  is  most  sensible  to  store  the  input  values  that  are  used  through¬ 
out  the  Simulation  for  executive  control.  This  approach  may  not  be  the  best 
model  to  achieve  this  effect.  Section  7.2  contains  discussion  of  alternate  solu¬ 
tions. 

This  seaion  has  outlined  the  operation  of  the  Easy_Sim  Modifier  class. 
The  next  section  looks  at  the  Easy_Sim  View  and  V'iew_Manager  classes. 

4.8  The  View  Classes 

The  View  class  provides  the  ability  for  the  user  to  look  into  the  Simulation,  and 
each  View  can  be  thought  of  as  a  different  window  into  the  scene.  A  View 
must  be  attached  to  a  Player  within  the  Simulation.  The  View31anager  class  is 
responsible  for  administering  multiple  Views,  and  it  keeps  track  of  the  list  of 
View  states.  Each  View  state  contains  a  Player  and  the  offset  and  rotation  of 
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the  last  View  that  was  attached  to  that  Player.  This  section  exa.mines  the  i.n]* 
plementation  of  the  View  and  View  Manager  classes.  Figure  19  shows  the 
Rumbaugh  diagram  of  the  View  class,  while  the  View_Manager  can  be  seen  in 
Figure  21. 

The  View  class  maintains  attributes  for  the  Modifier  and  Player  with 
which  It  is  associated,  its  local  Coords  relative  to  the  Player,  and  the  Performer 
types  Channel  and  Scene.  The  Get  and  Set  attributes  for  the  CCiuponGm  classes 
are  straightforward.  The  Performer  types  are  controlled  by  the  View,  and  Set 
procedures  are  not  available  for  them,  although  they  can  be  accessed  with  Get 
functions.  The  Set  procedures  for  Coords  all  expect  local  coordinates,  and  the 
Gets  on  the  entire  Coords  structure  also  return  values  relative  to  the  Player. 
However,  the  Get  functions  all  return  world  coordinate  values,  as  they  com¬ 
bine  the  local  Coords  with  the  Player’s  world  coordinates  by  using  matrix 
transformations. 

The  View's  controlled  Initialize  procedure  creates  a  new  Scene  that 
serves  as  the  root  of  the  rendering  tree  for  the  items  in  that  View.  The  Con 
figure  operation  is  rather  busy  in  the  View  class.  The  Configure  takes  the 
processing  Pipe  on  which  the  Simulation  is  operating  as  a  parameter,  and  the 
Pipe  Is  required  by  Performer  to  allocate  the  Channel.  Configure  also  fastens 
the  Scene  to  the  Channel  and  sets  up  default  values  for  the  angles  that  the 
View  can  see.  Finally,  Configure  establishes  the  callbacks  for  Performer’s  cull 
and  draw  processes. 

The  Cull  and  Draw  procedures  provide  default  implementations  for  their 
respective  threads  for  the  given  Channel.  Cull  calls  Performer’s  cull  function, 
while  Draw  first  clears  the  Channel  and  then  calls  the  Performer  draw  func¬ 
tion.  Pre.Cull,  Post_Cull,  Pre_Draw.  and  Post.Draw  procedures  are  provided  by 


Eas3'_Sim,  although  thej’  were  omitted  from  Figure  19  due  to  space  constraints. 
They  are  called  before  and  after  their  respective  Performer  functions  to  allow 
maximum  flexibility  in  application  customization.  They  all  default  to  null  ex¬ 
cept  Post_Dra\v,  which  -nakes  the  Performer  utility  cal!  to  collect  user  input. 

Because  of  the  currently  unresolved  incompatibilities  between  the  C- 
based  Performer  execution  and  the  Ada  9X  callbacks,  no  Ada  variables  can  be 
accessed  Inside  any  of  the  callback  operations,  either  globally  or  through  the 
parameter  list.  However,  as  this  process  was  not  necessary'  to  achieve  a  work¬ 
ing  simulation,  not  much  effort  was  put  forth  in  finding  a  solution.  Section 
7.2.2  addresses  possible  corrections  to  this  dilemma. 

The  incompatibility  beoveen  the  languages  also  affects  the  ability  of  the 
application  developer  to  customize  the  callback  operations.  Because  the  Con¬ 
figure  operation  establishes  the  procedure  to  which  the  callback  occurs,  it 
must  be  overridden  first.  The  new  Cull  or  Draw  procedure  must  also  be  over¬ 
ridden,  and  then  any  Pre  or  Post  operations  on  it  can  also  be  jedefined.  While 
this  process  seems  like  extra  work,  C+-  also  does  not  allow  callbacks  to  virtual 
functions,  and  a  similar  strategy  must  bs  applied  there. 

The  final  View  class  operation,  Update,  first  updates  its  local  Coords  with 
any  new  changes  from  the  Modifier.  It  then  calls  its  own  Get  functions  to  ob¬ 
tain  its  Position  and  Direction  in  world  coordinates,  and  it  passes  this  informa¬ 
tion  to  Performer  so  that  the  View  can  be  placed  correctly  to  look  into  the 
Scene. 


The  View  Manager  class  maintains  two  lists,  the  multiple  '/ieivj  and  the 
View  Stares.  The  controlled  operations  and  Configure  currently  are  all  null 
operations.  Because  no  testing  has  been  performed  with  multiple  Views,  their 
discussion  here  is  limited.  The  remainder  of  this  seaion  discusses  View  States. 
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M’  Jtlple  Views  can  be  added  to  the  Views  list  by  the  Add  procedure.  Like 
the  Player_Manager.Add,  this  procedure  increments  the  Count,  places  the  new 
View  into  the  Views  list,  and  calls  Configure  on  the  new  View  passing  the  Pipe 
parameter  it  was  given.  The  Set_View  procedure  takes  a  given  View,  finds  it  in 
the  Views  list  using  an  Index  function,  and  activates  it  by  setting  a  Boolean 
flag.  The  Update  procedure  iterates  through  the  Views  list,  and  calls  Update  cn 
the  Views  which  are  activated. 

The  Set_PIayer  procedure  takes  a  View  and  a  Player  with  the  intent  of 
attaching  the  View  to  the  Player.  The  use  of  View  States  allows  the  View  to  be 
placed  at  the  same  offset  and  rotation  from  the  Player  as  the  last  View  that  was 
attached.  In  order  to  achieve  this  effect,  the  first  step  in  this  procedure  is  to 
remember  the  current  state  of  the  Player  being  detached.  This  step  is  ac¬ 
complished  by  a  procedure  within  the  body  of  the  package,  Ssv£_S:s:£.  The 
next  step  is  to  call  the  View.Set_Player  procedure.  Finally,  the  Coords  of  the 
View  must  be  assigned  to  the  last  state  associated  with  the  new  attached  Player. 
This  step  is  performed  by  another  hidden  subprogram,  the  Offset  function, 
which  recovers  the  old  state  from  the  Statci-  list. 

This  section  has  summarized  the  implementation  of  the  View  and 
View_Manager  classes.  The  final  section  of  this  chapter  highlights  the  opera¬ 
tion  of  the  Easy..Sim  Simulation  class,  which  Is  the  capsiobe  of  the  Easy.Si.m 
framework. 

4.9  The  Simulation  Class 

The  abstract  Simulation  class  provides  the  structure  to  bring  all  of  the  pieces 
in  a  visual  simulation  together.  The  basic  interaalon  with  Performer  occurs 
in  this  class,  establishing  the  foundation  of  the  applicailon.  This  section  de- 
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scribes  the  implementation  of  the  Simulation  class.  Figure  22  shows  the  Rum- 
baugh  Object  Model  representing  the  Easy_Sim  Simulation  class. 

The  controlled  operations  for  the  Simulation  class  respectively  call  the 
Init  and  Exit  functions  of  Performer.  The  Configure  procedure  has  a  long  list 
of  parameters,  all  of  which  provide  information  to  configure  Performer  dif¬ 
ferently.  and  all  of  which  have  norma!  default  values.  These  parameters  ad¬ 
dress  such  items  as  the  frame_i?ate  desired  for  the  application;  the  Input_Mode 
that  will  be  used  to  gather  user  input,  the  Message^Level  describing  the 
amount  of  processing  Information  the  user  would  like  displayed  to  the  console, 
and  so  on.  Configure  uses  all  of  these  parameters  to  prepare  the  application; 
and  finally  calls  Performer's  InitPipe  function  which  performs  a  callback  to 
Open_VVindow  to  start  the  Simulation. 

Open.vvindow  is  implemented  as  a  separate  subunit  because  it  is  the 
only  part  of  Easy.Slm  which  uses  GL  functions.  It  calls  Application_Name  as  it 
issues  the  window  opening  command  so  that  the  application  developer  can 
customize  the  title  of  the  window  in  which  the  simulation  is  rendered.  Just  as 
the  callbacks  in  the  View  class  have  inter-language  communication  problems, 
so  does  the  Open_Wlndow  procedure.  Any  attempt  to  access  the  application 
name  globally  or  through  parameters  fails,  and  the  function  call  is  used  be¬ 
cause  it  works. 

The  Simulation  class  has  five  attributes.  Environment,  Model_Manager, 
Player.Manager,  and  View.Manager  are  all  class  References,  and  they  have 
both  Get  and  Set  attributes.  The  Set  attributes  for  the  manager  classes  act 
slightly  differently  than  normal  Set  operations,  because  they  all  take  null  val¬ 
ues  by  default  and  allocate  themselves  the  first  time  they  are  called.  This  im¬ 
plementation  was  chosen  because  of  the  privacy  problem  caused  by  subclasses 


102 


not  being  able  to  access  the  components  of  their  parent  (see  Section  6.3).  Al¬ 
ternatively,  the  managers  could  all  be  allocated  in  Initialize,  but  this  approach 
prevents  them  from  being  overridden  easily.  The  fifth  attribute  is  Pipe,  the 
processor  model  from  Performer.  This  value  is  initialized  in  Configure  and 
cannot  be  changed.  Pipe  therefore  only  has  a  Get  function  associated  with  it. 

The  Simulation  class  declares  three  overloaded  Add  procedures,  to  re¬ 
spectively  add  the  Environment,  a  Player,  or  a  View  to  the  Simulation.  These 
operations  are  where  the  Simulation  ties  all  of  its  pieces  together.  The  Add 
View  must  be  called  before  the  others,  so  that  they  can  be  placed  in  a  V^ew. 
Add  View  takes  a  New-View,  a  Player  to  which  It  will  be  attached,  a  Modifier  if 
one  Is  needed,  and  either  a  set  of  Coords  or  a  file  from  which  the  Coords  can  be 
read.  The  procedure  first  calls  View’..vianager.Set_Player  with  the  given 
Player  and  then  calls  Set_.Modlfier.  These  steps  fasten  these  items  to  the  View, 
The  next  step  calls  View.Set«Coords  to  set  the  offset  from  the  Player,  either  by 
assigning  the  given  Coords,  or  by  calling  Read_Coords  to  retrieve  the  data  from 
a  file.  The  latter  method  allow’s  applications  to  be  easily  changed  without  re¬ 
compilation.  Finally,  the  Add  View  procedure  calls  V'iew.Manager.Add,  and  the 
View'  becomes  part  of  the  Simulation. 

The  Add  Environment  procedure  takes  parameters  for  the 
New^Environmem,  a  View  to  which  is  attached,  and  a  ModeLFUe  containing 
the  graphics  database.  The  procedure  first  calls  Model.Manager.Assign_Model 
and  Environment.Set_Model  to  get  the  Model  and  attach  it  to  the  Environment. 
Environment.Configure  is  called  next,  passing  the  Channel  and  rendering 
subtree  so  that  any  necessar>'  linking  between  the  Environment  and  the  View 
can  occur.  The  final  step  is  to  call  Set_Envlronment  with  the 
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New_Environment,  ensuring  that  the  Simulaiion  is  also  properly  tied  to  its 
background. 


The  third  and  final  .-^dd  procedure  adds  a  NeuLPJsyer  to  the  Simulation, 
and  it  combines  the  features  of  the  other  two  Adds.  Add  Player  takes  parame¬ 
ters  for  the  V'iew  it  appears  in,  its  ModeLFile,  and  either  method  of  passing  its 
Coords.  Like  Add  Environment,  it  first  calls  Model. Manager.Assign_Model  and 
Player.Set_Model.  Like  Add  View,  it  then  calls  Player.Set.Coords,  perhaps  by 
reading  from  a  file  first.  Finally,  Add  Player  calls  Player.Manager.Add  to  en¬ 
sure  that  the  Player  becomes  part  of  the  Simulation. 


The  culmination  of  the  Simulation  occurs  in  its  Render  procedure.  This 
procedure  loops  continually,  causing  Performer  to  draw  the  application  on  the 
display.  Render  first  calls  Performer's  Sync  function  to  coordinate  all  three 
Performer  threads  on  a  frame  boundary'.  !t  then  calls  Yiew.Manager.Updaie  to 
Update  the  positions  of  all  the  Views.  Render’s  call  to  the  Performer  Frame 
function  causes  the  start  of  the  cull  and  draw  threads.  The  Player.Manager.- 
Update  is  called  next,  to  move  all  the  Players  In  the  Simulation.  Finally,  the 
Simula' 'on  calls  its  own  abstract  Update  procedure,  allowing  any  overriding 
functionality  of  Its  subclass  to  be  incorporated  into  the  main  rendering  loop. 
Usually,  user  input  that  controls  the  flow  of  the  application  is  processed  here, 
possibly'  ending  the  loop.  Otherwise,  another  frame  Ls  drawn,  and  so  on... 


This  chapter  has  described  the  implementation  of  the  Easy_Slm  applica¬ 
tion  framework.  Most  of  the  discussion  here  holds  in  both  the  Ada  9X  and  C-^-+ 
versions,  with  the  differences  described  in  Section  6.3,  Instructions  on 
obtaining  the  Easy_Sim  code  appear  in  Section  7.3.  The  next  chapter  describes 
an  Ada  9X  implementation  of  an  example  application  using  the  Easy_Sim 
sofware  architecture  and  application  framework. 
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V  Example  Application 


This  chapter  describes  how  to  develop  a  basic  visual  simulation  using  the 
Easy_Sim  application  framework.  It  first  does  this  by  presenting  an  example 
application,  the  Circling  Planes.  The  example  leads  the  reader  through  the 
entire  application  development  process.  The  chapter  ends  by  illustrating  gen¬ 
eral  guidelines  for  deriving  from  the  different  Easy_Sim  classes  to  develop  anj’ 
application. 

5.1  The  Circling  Planes  Example  Application 

This  section  covers  the  complete  development  of  an  Ada  9X  solution  for  an 
application.  The  overall  plan  for  the  simulation  Is  described  first,  and  then  a 
detailed  look  at  each  of  the  necessary'  components  follows. 

This  simulation,  Circling  Planes,  involves  two  aircraft  circling  over  a 
ground-based  background  and  a  obser\'at5on  point  from  which  the  planes  can 
be  tracked.  The  simulation's  view  can  be  attached  to  either  of  the  planes  or  the 
tracker  point,  and  can  be  switched  between  these  entities  by  using  the  mouse. 
This  application  is  taken  from  Example  2  in  the  ObjectSim  .Application  Develop¬ 
er’s  Manual  [Sny93Ak7-16]. 

The  Circling  Planes  simulation  mainly  uses  the  default  classes  supplied 
by  the  Easy_Slm  framework,  but  It  also  derives  application  specific  compo¬ 
nents  from  Easy_Sim's  abstract  classes.  Figure  26  shows  an  Object  Model  dia¬ 
gram  representing  the  overall  design  of  the  system,  with  the  Easy_Sim  frame¬ 
work  shown  in  the  top  portion,  and  the  application  specific  classes  shown  in 
the  lower  portion.  Bold  lines  show  inheritance  relationships,  while  normal 
lines  show  aggregations  and  regular  associations. 
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Figure  26.  Circling  Planes  Simulation  Objca  Model  Diagram 


The  Player  class  provides  the  basis  for  both  the  Plane  and  Tracker 
classes,  and  each  Tracker  is  related  to  the  Player  it  follows,  (This  association  is 
restricted  to  Planes  in  Figure  26  to  keep  too  many  lines  from  crossing.)  The 
application  background  uses  Easy_Sim's  standard  Terrain  class,  and  therefore 
includes  basic  representations  for  the  Horizon  and  Sun.  input  is  entered  into 
the  application  through  the  use  of  Easy_Sim’s  StandardJnput  Modifier  class, 
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which  provides  services  for  keyboard  and  mouse  entries.  Finally,  the  Cir- 
cling_Planes  class  is  derived  from  Easy_Sim’s  Simulation,  and  serves  to  con¬ 
nect  all  of  the  pieces  to  make  the  application. 

The  remaining  portions  of  this  section  concentrate  on  each  of  the 
classes  derived  to  make  the  Circling  Planes  example.  Because  these  classes  are 
not  part  of  the  Easj  _Sim  application  framework,  they  are  not  declared  as  child 
packages  of  Eas3’_Sim.  Instead,  they  each  stand  alone.  The  Plane  class  is  the 
first  to  be  examined. 

5.1.1  The  Plane  Qass 


In  order  to  simulate  an  entity  within  an  Easy_S!ro  application,  a  subclass  of  the 
Player  class  must  be  defined.  To  simulate  a  plane,  the  new  class  is  appropri¬ 
ately  named  Wane.  An  instance  of  the  Plane  class  moves  by  simply  moving 
forward  and  changing  Its  heading  to  the  right  each  frame,  making  a  clockwise 
circle. 


To  Implement  this  design  in  Ada  following  the  Easy_Sim  architecture,  a 


class  package  named  Plane  is  created  which  derives  its  class  Object  from 
Easy_Sim.Player.Object.  This  step  requires  access  to  Easy_Sim.Player  through  a 
with  context  clause.  The  Plane  class  does  not  need  to  add  any  attributes  to  the 


Player  class,  and  inherits  the  majority  of  i 


rc 


oneraTion'i  'uitVimir  mnHi. 


flcation.  To  be  consistent  with  Easy_Sim  structure,  the  Plane  class  declares  a 
classwide  access  type,  Reference,  and  places  its  attribute  extensions  in  the  pri¬ 
vate  part.  The  circling  movement  of  the  Plane  is  accomplished  by  overriding 
the  Player’s  Update  procedure.  Finally,  the  Player’s  abstract  Draw  procedure  is 
also  overridden,  but  because  no  special  drawing  Is  needed  in  this  application, 
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with  Easy_Siin.Playsr; 
pacKaga  Plane  ia 

type  Object  ia  new  Easy_Sirri. Flayer. Object  with  private: 

typo  Reference  ia  aeceaa  all  Object* Class; 

procedure  Update  (Instance  :  in  out  Object}; 

procedure  Draw  (Instance  ;  in  out  Object); 

private 

type  object  ia  new  Easy^Siti. Player .Object  with  null  roeord: 
end  Plane; 

Figure  27.  Plane  Class  Package  Specification 

this  operation  does  nothing.  Figure  27  contains  the  Ada  package  specification 
for  the’Plane  class. 

The  body  of  the  Plane  package  is  slightly  more  complex.  The  body  first 
shows  its  dependence  on  the  Performer's  pf  library  by  accessing  it  via  the 
wnii  clause.  The  Plane  implementation  also  introduces  the  Basic.Tj'pes  pack¬ 
age,  which  is  implemented  to  provide  Ada  types  analogous  to  the  C  types  used 
in  Performer.  The  Update  procedure  then  moves  the  Plane  forward  by  calling 
its  inherited  Move_Straight  procedure,  and  decrements  the  Plane's  heading  by 
using  Get  and  Set  operations  and  a  temporary  variable.  The  use  of  this  vari¬ 
able  ensures  that  the  Plane's  heading  stays  within  a  realistic  range.  The  final 
step  in  Update  is  to  change  the  coordinates  for  the  Plane  In  the  rendering  tree, 
and  this  step  is  accomplished  by  means  of  a  Performer  call.  The  implementa¬ 
tion  of  the  Plane  class  is  completed  by  providing  a  dummy  procedure  to  over¬ 
ride  the  Draw  procedure.  Figure  28  shows  the  body  of  the  Plane  package. 
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with  Performer_Pf ; 
with  Bs.sic_Types; 

packaga  body  Plane  is 


*^oe®dura  Update  (Instance  ;  in  out  Object)  is 
lJev.’_Keading  :  EaEic_TypeE . Float32  :s  C.C; 
begin 

Have_Stcaight  i Instance,  4.0;; 

Kew_H€adina  :=  Heading  (Instance)  -  0.5; 

if  Kew_Heading  <  0.0  than  --  Wrap  around  if  full  circle 
Mev_Heading  :=  360.0; 

•nd  if; 

Sat_H€ading  (Instance,  Nev:_Keadir,g) ; 

Performer_Pf .PfDCSCnorc  (Image  (Instance),  Ccords  (Instance)); 
end  Update; 


procedure  Drav;  (Instance  ;  in  cut  Object)  is 
begin 
null; 
end  Draw; 


end  Plane; 


Figure  28.  Plane  Class  Package  Body 


5.1.2  The  Tracker  Class 


To  observe  the  circling  planes,  another  Player  subclass  is  defined,  the  Tracker. 
This  class  has  no  model  of  its  own,  and  merely  exists  to  watch  another  Player. 
Like  the  Plane  class,  the  Tracker  class  Inherits  the  majority  of  Its  attributes 
and  operations  from  Player,  It  does  add  an  attribute  however,  Trsekes,  to  store 
a  Reference  to  the  Player  being  tracked.  It  also  adds  a  Set  operation  to  modify 
Its  new  attribute.  Tracker  overrides  Update  to  define  its  tracking  techniques, 
and  must  override  Draw  to  become  concrete.  Tracker  also  redefines  Initialize 
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with  E*sy_SiTri. Flayer ; 
package  Tracker  is 

type  Object  is  new  Easy^Sisn. PI aver .Object  with  private; 

type  Reference  is  access  all  Object ‘Class; 

procedure  Initialize  (Instance  :  in  out  Object); 

procedure  Update  (Instance  •,  in  out  Object); 

procedure  Set_Track66 

(Instance  ;  in  out  Object; 

ro_Trackee  :  in  Easy_Sirr.. Player  .Reference)  ; 

pragma  Inline  (Set_Trackee) ; 

private 

type  Object  is  new  Easy_Sin'..  F.  yer. Object  with 
record 

Trackee  :  Easy_Sim. Player .Reference; 
end  record; 

end  Tracker; 

Figure  29.  Tracker  Clas.s  Package  Specification 

here  to  demonstrate  this  process,  even  though  It  is  not  necessary.  Figure  29 
outlines  the  Tracker  package  specification. 

The  body  of  Tracker  is  similar  to  Plane,  but  due  to  Its  lack  of  a  Model,  has 
no  dependency  on  Performer.  The  Initialize  procedure  here  is  superfluous, 
but  serves  to  show  the  concept  of  view  conversion.  To  reuse  the  steps  in  ini¬ 
tializing  Its  inherited  components,  Tracker-lnitialLe  simply  calls  its  parent's 
operation.  Logically,  this  call  passes  only  the  components  of  the  parent  record 
tvTJe,  and  Tracker  is  free  to  initialize  its  new  components  afterwards.  The  Up¬ 
date  procedure  uses  the  inherited  Look_At  procedure  to  orient  the  Tracker  to¬ 
wards  the  position  of  the  Trackee.  It  finds  this  position  by  dereferencing  its 
component’s  pointer  and  calling  the  Get  operation  on  the  Player.Object’Class  to 
find  its  location.  This  technique  works  on  any  Player  subclass,  as  the  tag  of 


no 


p«ek«g«  body  Tracker  is 


procedure  Initialize  (Instance  :  in  out  Object J  is 

begin 

Easy_Sim. Player. Initialize  {Easy_Sin. Player. Object  ilnstance) ; ; 
Instar.ce.Trackse  :=  null; 
end  Initialize; 


procedure  Update  (Instance  ;  in  out  Object;  is 

begin 

Lcok_At  (Instance,  Easy_£ini.  Player  .Position 

(Instance .Trackee .all) ) ; 

cad  Update: 


procedure  Set_Trackee 

(Instance  :  in  out  Object; 

Tc_Trackee  :  in  Easy_£ini. Player .Reference)  la 

begin 

Ir.stance.Trackee  ••=  To_Trackee; 
end  Set_Trackee: 


procedure  Craw  (Instance  ;  in  out  Object)  Is 
begin 
null; 
end  Orav.-; 


end  Tracker; 


Figure  30.  Tracker  Class  Package  Body 


Trackee's  designated  object  dispatches  the  call  to  the  ^.^propriate  Position 
function.  Figure  30  contains  the  body  of  the  Tracker  class  package. 

5.1.3  The  Clrcling.Planes  Class 


As  stated  in  the  design  chapter,  the  Simulation  class  serves  as  the  organiza¬ 
tional  fulcrum  of  the  application,  tying  together  all  of  the  simulation’s  pieces. 


This  application,  Circling^Planes,  is  no  different.  The  context  clauses  show 
that  it  uses  the  Easy^Sim  classes  as  building  blocks.  The  class  t>'pe  is  derived 
from  Eas3'.Sim.Simulation.Obiect,  and  its  attributes  defi.ne  the  entities  inyolved 
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with  H£5y_Sira .  Player ; 
with  Easy_Siin. Modifier; 
with  Easy_Sir..View; 
with  Easy_Sirr..Sirp.ul£tion; 

package  Circling_Flan£s  is 

type  Object  is  new  Easy_Siia. Sinulat ion. Object  with 
private ; 

type  Reference  is  access  all  Object 'Class, • 
procedure  Initialize  (Instance  :  in  out  Object}; 
procedure  Update  (Instance  :  in  out  Object); 

Cuit_Progra3ti  :  exception; 
private 

function  Application_Nan'.e  (Instance  :  access  Object; 
return  String; 

type  Object  is  new  Easy_Sin>. Simulation. Object  with 
record 

Mair._Vie•.^’  ;  EaEy_Sim. View. Reference; 

Tracker  ;  Eesy_Siir..  Player  .Ref  erer.ee; 

Fli5ht_Lead  :  Easy_Sir.. Player .Reference; 

Wing_>l&n  :  Easy_Sirr..  Flayer  .Reference; 

Input  :  Easy_Sirr..Modifier  .Reference; 

end  record; 

end  Circling_Plan6s; 

Figuie  31.  Clrcling_PIanes  Qass  Package  Body 


in  the  application.  There  is  one  View,  .Afain.V/ew;  three  Players,  Tracker, 
Flighc^Lead  and  Wing^Man;  and  one  input  device,  Input.  The  constpjcior, 
Initialize,  defines  the  relationships  between  the  different  attributes,  and  Up¬ 
date  defines  how  Input  affects  the  Simulation  each  frame.  An  exception, 
Quit^Program,  pro\ndes  an  avenue  for  gracefully  exiting  from  the  inherited 
Render  loop.  Finally  an  overriding  private  function,  Appllcation_Name,  al¬ 
lows  the  window  to  be  labeled  with  the  title  of  this  example.  Figure  31  holds 
the  code  for  the  Circling_Planes  specification. 
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with  Perfomer_Pf ; 

with  ?erfomer_?futil  : 

with  E&sy_Sir..ErA*ironrent .Ter rain; 

with  Z£sy_£in'..Mcdif ier .Standard_Inrur ; 

with  Plane; 

with  Tracker; 

package  body  Circli.nc;_Planes  la 

procedure  Initialize  {Inetance  :  in  out  Object:  ia  (in  Pigure  22}; 
procedure  Update  ;instan“e  :  in  out  Object}  ie  ;in  Figure  24'; 

function  Applicaticn_Karre  llnstance  t  acceea  Object) 
return  Otring  ia 
begin 

return  (■Iasy_£im  Circling  Planes  Exa.*sple”); 
end  .\pplication_Kain= ; 

end  Circling_Planss ; 

Figure  32.  Skeleton  of  Cirding.Plancs  Class  Package  Body 


The  body  of  the  Circling.Planes  package  establishes  the  relationships 
between  the  different  entities  in  the  simulation,  and  assigns  the  appropriate 
subclasses  for  the  different  attributes.  These  .subclasses  are  accessed  by  the 
collection  of  with  clauses  that  precedes  the  program  unit.  Figure  32  shows  the 
Circling^Planes  class  body.  The  code  is  too  large  to  show  at  once,  however,  so 
the  figure  only  presents  part  of  the  body,  and  discussion  of  Inirlali??  and  Up¬ 
date  follows  below.  The  one  operation  shown.  Applicatlon^Name,  is  called  just 
before  the  window  for  the  simuiation  is  opened,  and  U  provides  the  name  that 
appears  in  the  corner  of  the  window.  Because  this  function  is  specific  to  this 
application  and  only  needs  to  be  called  once,  ft  Is  declared  In  the  private  part 
of  the  package  specification. 

Figure  33  shows  the  Initialize  procedure  of  ClrcIlng_P!anes  by  itself.  It 
first  calls  Its  parent’s  Initialize  and  Configure  operations  so  that  Performer 
and  the  Easy_Sim  framework  are  initialized.  Most  of  the  parameters  of  Config¬ 
ure  take  their  default  values,  but  the  Modifier  in  this  application  uses  Per¬ 
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procedur*  Inirialise  (Instance  :  is  out  Ob'ect;  is 

Initialization  of  Terrain  muet  occur  after  PfConfic, 
VJhich.  is  called  in  Sir.-i.Init,  so  allocation  roust  wait 
Terop_7errair.  :  Easy_Siro,. Enviror.roent.Referer.ee; 

begin 

£asy_Siro..S:r!!‘  ;  cn .  I.nitiali ze 

(Easy'_Sj’  ’  ion.Cbiert  (Instance’!'; 

Configure  (1..-  -=, 

Input_liode  =>  Perf orroer_Pfutii . PFJIKP"T_GL) ; 


Instance  .Main_Vi6w  :=  new  Ea6'/_Sim. View. Object ; 

Instance. Tracker  :=  nevr  Tracker .Object ; 

Instance. Flight_Lead  ;=  new  Plane .Object ; 

Instance .Wing_Man  :=  new  Plane . Object; 

Instance .  Input  :=  new  Easy _Siir.. Mcdif  ler  .Standard_Input  .Object ; 
Temp.Tcrrain  :=  new  Easy_Sim.Envircnir.ent  .Terrain. Object ; 

Add  (Instance,  ::ev.-_Vi ev.’  =>  Instance .Main_'’’ev.*, 

With_Play6r  *>  Instance .VJir.g.  an, 

V*ith_>!odif ier  »>  Instance . Inpu 

Coords_File  =>  ‘view. data" ) 


.Add  (Instance,  New_?:ayer  =>  Instance. Tracker, 

Cccrds_File  =>  •tracker.data*: ; 

Tracker .Set_Trackee  {Trac’<er .Reference  (Instance .Tracker) .ell, 

Instance .Flight _Lead) ; 


Add  (Instance, 

Kev.'_Playsr 

s> 

Instance .Flight.Lead 

Coords_File 

B> 

•lead, data" , 

Model.File 

Sf> 

•lead. fit") ; 

Add  (Instance, 

Nev'_  Player 

2> 

Instance .  Wing_Mar. , 

Cocrd6_?cle 

*> 

•wing. data". 

Hcdel_?iie 

s> 

•wing. fit"; ; 

Add  (Instance,  Nev.-_E.Tv*ironme.'>t  =>  Ten;c_Terrain, 

Kodel_File  =>  "terrain. fit*) ; 


end  Initialise; 

Figure  33.  QrcILng_PJincs  Class  InltJaJiic  Prcccd'jrc 


former's  GL  mode  of  reading  input,  and  the  default  X  Windows  input  mode  is 
therefore  overridden. 

Initialize  then  allocates  each  of  its  attributes,  and  they  are  allocated 
with  particular  subclasses.  Declaring  the  attributes  in  the  specification  as 
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base  classes  and  allocating  them  in  the  body  as  subclasses  allows  more  flexi¬ 
bility  In  their  handling  in  the  application.  Attributes  inherited  from  the 
Simulation  class  are  private,  so  the  Environment  and  various  Manager  at¬ 
tributes  cannot  be  accessed  or  allocated  directly  here.  The  use  of 
Temp_Terrain  shows  a  method  for  bypassing  this  annoyance  when  necessaiy. 
The  default  manager  clas.ses  all  allocate  themselves  when  they  first  are  refer¬ 
enced  to  ciroimvent  this  privacy  problem. 

The  relationships  among  the  Environment,  Modifier,  Views,  Players, 
and  Managers  are  all  incorporated  into  the  simulation  by  using  the  various 
Add  procedure  calls  and  Set  operations  where  appropriate.  The  Add  operations 
allow  files  containing  rendering  models  to  be  specified  for  the  En\1roninent 
and  any  Players  that  need  them,  and  the  Adds  also  allow  the  Initial  coordinates 
for  the  Views  and  Players  either  to  be  passed  explicitly  or  read  from  a  file. 
Using  files  for  reading  Models  and  Coords  aHows  the  developer  to  customize  the 
application  by  simply  changing  the  models  or  coordinates  contained  in  a  par¬ 
ticular  file.  This  flexibility  saves  inefficient  recompilations  should  different 
values  for  these  attributes  need  t'*  '•'  ?  tested  or  used  In  a  simulation. 

The  Update  procedure  of  the  Clrcling_Planes  package,  shown  alone  In 
Figure  ?  ’  allows  user  input  to  change  the  state  of  the  simulation  each  frame. 
The  user  can  press  the  capita!  5  to  toggle  Performer’s  statistics  displays  or 
press  the  Escape  key  to  quit  the  program.  By  using  the  mouse,  the  user  can 
attach  the  View  to  the  different  players  in  the  application.  The  left  mouse 
button  corresponds  to  the  Tracker,  the  right  butter,  attaches  to  the  lead  Plane, 
and  the  middle  button  moves  the  View  to  the  following  Plane. 
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procwdur*  Update  (Instance 


in  out  Object)  i* 


Input_FlasS 


r4sy_siir;.Hodif  ier  .Sc£nd&rd_Input  .riags_Pointer 


begin 


j"  t_Fiacs  :=  EaEV.Sim.Modifier.Star.dard^Input.Flag.Ccpy 
(Easv  Sis'. Modifier.Standard_Ir.pvit. Object 

•Elsy.Situ View. Modifier  '.Instance. MaanJ/iew. all,  .all.) 


if 


Input  Flags. Key_Down  CS'}  then 

:nput'’Flags.Draw_Stats  ;=  not  lnput_rlags .Drav.-_Stats; 
inputlFlags.Key_Dcv.-n  (’S')  ;=  False; 


elaif  Incut_FlagE.Key_Dov.T.  (Ascii. Esc',  than 
Input_Flags.Quit_Progr£.'n  :=  True: 

raiaa  Quit_?rt>cran; 


alalf  lr.put_Flags.Left_Mouse_D’owri  than 

Iriput_Flegs  .Ieft_Kcuse_Down  :=  False; 

Eaey-Siir. .  Vi  ev.* .  ^3anager .  £st_Pla-ysr 
( Vi«v.-_Manager  ( Instance  > .  all ,  ^ 
OiJ'viev  =>  Instance.Main_Vie-.-.’, 
ToIp1«^Y®-  =>  Instance. Tracker )  ; 

alaif  Input.Flags.Kiddle.House.Dcwn  than 

Inputlrlags .Kiddl€_Kcus€_Ocwn  :=  False; 

Sasy.Siir. .  View  .Manager .  Set^Player 
(View_Mana5er  (Instance) .all, 

Of_View  ®>  Instance .Main_View, 
To~Play®-  Instance  .VJir.g_M£r.) ; 

alaif  Ir.put_Flags.Right_Ncuse_rcwn  then 

Input_Flags.Rignt_Kcuse_Dcwn  :«  False; 


Easy_Siir..  View. Manager. £st_Player 
(Vi€V.-_Kanager  (Instance)  .all, 

Of_Vicw  e>  Instance. Main_Viev7, 
To_Player  =>  Instance  .FIight_l,ead',  ; 

and  if ; 


if  lnput_Flags  .Drav-_Stats  than 
Ferfcrner_Pf  .PfDrav.-ChanStats 

;Eas-y_Sim.View.Cnann6l  (Instance  .Kain_View.all) ) ; 

and  if; 


and  Update; 

Figixre  34.  Circling_Planes  Class  Update  Procedure 
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User  input  results  In  the  setting  of  global  input  flags  within  the 
Easy_Sim.Modifier.Standard_Input  package.  The  Update  procedure  calls  Flag_- 
Copy  to  gain  access  to  the  input  flags  and  monitors  those  in  which  it  is  inter¬ 
ested.  When  one  of  these  flags  is  set,  Update  generally  resets  it  and  acts  appro¬ 
priately.  For  the  mouse  operations,  this  action  is  to  call  the  View_Manager  to 
switch  the  Player  to  which  the  View  is  attached. 

5.1.4  The  Applicatlon_Drlver  Program 


With  all  of  the  organization  accomplished  in  the  Circling_Planes  package,  the 
driver  has  little  left  to  do.  The  AppIicatfon^Drlvsr  procedure  is  shown  in  Fig^ 
ure  35.  The  driver  declares  the  Simulation  object,  whose  initialization  is  per¬ 
formed  automatically  by  constructor,  and  then  calls  Render  on  Simulation. 
This  operation  does  not  complete  until  the  user  hits  the  Escape  key. 


with  CircLing_?lar.es; 
proeadur*  Applictticn_Driver  Is 

Simulation  s  Circling_Flanes .Object ; 

bagia 

Circlir.g_Plar.es  .Render  (Simulation) ; 

•nd  Application_Driver ; 

Figure  35.  Circling_Planes  Simulation  Driver  Procedure 


The  Circling  Planes  example  has  shown  the  development  of  one  specific 
Easy_Sim  application.  The  following  section  provides  more  general  guidance 
for  developing  applications. 
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5.2  General  Application  Development 

This  section  describes  the  entrj'  points  in  the  Easy_Sim  software  archi¬ 
tecture  where  different  types  of  functionality  may  be  added  to  enhance  a 
simulation.  Many  of  these  concepts  are  also  presented  in  vM. lier  chapterSi  btit 
they  are  summarized  here.  The  abstract  classes  are  analyzed  first  because 
their  customization  is  necessary  to  produce  a  working  application.  This  sec¬ 
tion  then  analj'zes  the  concrete  basic  classes,  and  it  finishes  by  covering  spe¬ 
cializations  of  the  manager  classes. 

The  most  basic  abstract  class  is  the  Player  class.  It  provides  the  basic 
component  for  differentiating  entity  behavior  within  a  simulation.  It  also 
supplies  the  architectural  connectors  that  serve  as  the  focal  points  for  defin¬ 
ing  the  different  aspects  of  that  behavior.  A  Player’s  behavior  can  be  simple, 
like  the  Plane  examined  last  seaion,  or  it  can  be  complex  and  consist  of  many 
different  pieces.  The  Plane  modeled  In  the  Virtual  Cockpit  application,  for  in¬ 
stance,  comprises  radar  capabilities,  an  inertial  navigation  system,  a  weapons 
delivery'  systems,  a  head's  up  display,  and  a  throttle  and  stick,  all  in  addition  to 
correctly  modeling  aircraft  flight  dynamics  ISny93,6R,Fig251. 

This  modular  approach  establishes  a  precedent,  whereby  a  subclass  can 
gather  functionality  from  many  smaller  classes  and  organize  this  functional¬ 
ity  in  one  place  to  suit  the  requirements  of  the  architecture  This  huHa’inp 
block  method  makes  creating  components  much  more  flexible  and  establishes 
a  set  of  modules  that  are  reusable  both  at  the  design  and  code  levels.  The 
building  block  approach  is  not  limited  to  the  Player  class.  !t  can  be  applied  to 
any  class  within  the  Easy_Sim  hierarchy. 

The  other  basic  abstract  classes  in  the  Easy.Sim  architecture  include 
Che  Environment  and  the  Modifier.  In  the  Circling  Planes  example,  the  Envi- 
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ronment  class  has  already  demonstrated  the  building  block  approach  to  mak¬ 
ing  simulation  backgrounds  by  combining  the  Horizon  and  Sun  classes  to  form 
a  Terrain  subclass  that  adheres  to  the  Environment's  predefined  structure. 
Similarly,  application  developers  can  extend  the  Modifier  class  to  handle  the 
user  input  into  their  applications.  The  possibility  exists  that  these  user  input 
devices  may  be  used  to  modify  Player  movement  or  control  the  Simulation  as 


well,  but  these  concepts  are  still  under  development. 


A  Aic  auoviavi  tjyt 


eration  In  Environment  forces  Its  subclasses  to  declare  any  intentions  of 


adding  application  specific  features  to  the  draw  thread.  Some  Environments 


may  be  aided  by  grids  or  text  overlays,  and  these  features  must  be  addeu 


UUl 


the  draw  thread. 


The  final  abstract  class  in  the  Easy_Sim  architecture,  Simulation,  is  the 
hub  of  the  Easy^Sim  concept.  Serving  to  coordinate  the  attributes  that  com¬ 
pose  it,  the  Simulation  supplies  architectural  connectors  so  that  the  applica¬ 
tion  developer  can  Isolate  the  location  where  organizational  algorithms  can  be 
used  In  an  application,  ,^s  the  Circling  Planes  example  demonstrated,  accom¬ 
plishing  the  coordination  during  initialization  simplifies  the  simulation  pro¬ 
cessing  later.  Because  the  Simulation  encompasses  all  other  classes,  it  is  re¬ 
visited  at  the  end  of  this  section. 


There  are  two  basic  concrete  classes  in  the  Easy_Sim  archlieaure,  of 
which  Model  is  the  more  basic.  The  Model  class  forms  a  module  isolating  the 
representation  of  graphical  images,  and  provides  default  behavior  to  process 
these  images.  Performer  allows  the  Model  class  to  be  flexible  enough  to  handle 
many  different  formats  of  images  and  automatically  adjust  for  level  of  detail 
control,  but  a  developer  may  still  need  to  customize  his  Models.  The  most  likely 


occurrence  would  b'  when  the  developer  must  work  with 


that  differs  from  the  Performer  conventions.  The  current  standards  for  dis¬ 
tributed  interactive  simulations  (DIS)  fall  into  this  categor>',  and  a  Model  sub¬ 
class  to  correct  for  this  discrepancy  is  warranted  in  DIS  applications. 

The  other  basic  concrete  class  in  the  Ea.sy.Sini  architecture  is  the  View 
class.  A  View  encompasses  window  displaying,  and  it  therefore  also  directs 
functions  that  are  tied  to  windowing.  These  include  user  input  and  the  ability 
to  affect  Performer’s  cull  and  draw  threads,  both  of  which  an  application  de¬ 
veloper  may  want  to  customize.  User  input  can  be  customized  through  the 
Modifier  class  to  accommodate  different  input  devices,  but  the  handling  of  the 
Input  data  may  fall  more  sensibly  in  the  View  class.  Customized  culling  can 
enhance  the  application’s  performance,  and  the  draw  operation  can  add  extra 
information  to  the  scene,  such  as  text  overlays. 

The  manager  classes  in  the  Easy_Sim  architecture  are  container  classes, 
each  of  which  directs  the  interaction  among  its  constituents.  The  default 
ModeUManager  prevents  duplicate  nodes  in  the  simulation’s  rendering  tree 
by  cloning  Models  that  are  used  more  than  once.  This  simple  default  design  cf 
the  Model_Manager  should  suffice  for  most  applications,  but  others  may  wish 
to  customize  how  the  Models  in  the  simulation  are  manipulated.  A 
Model-Manager  subclass  may  wish  to  define  different  techniques  for  level  of 
detail  control,  or  for  compatibility  with  a  different  coordinate  system.  A  sub¬ 
class  may  also  simply  require  another  avenue  for  assigning  the  Models. 

The  Player-Manager  class  also  forms  the  architectural  entry  point  for  a 
limitless  number  of  customizations  for  Easy_St.m  applications,  The  default  class 
provides  no  real  organization  of  the  Players,  but  different  subclasses  could 
institute  methods  for  optimizing  rendering  by  spatially  organizing  the  Players 
[Har94,i30].  An  application  could  add  collision  detection  into  Easy-Sim  appli- 
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cations  through  the  Player_Mar.ager.  Most  importantly  for  distributed  inter- 
active  simulations,  the  Player_Manager  class  pro\ides  a  sound  starling  point 
for  bringing  network  player  managers  into  the  architecture.  Ideally,  an  ab¬ 
stract  class  could  be  designed  that  is  general  enough  for  any  network  simula¬ 
tion.  Subclasses  could  be  derived  for  each  particular  application,  customizing 
its  specific  needs  according  to  a  standard,  understandable  architectural  plan. 

Like  its  other  manager  classes,  Easy_Siiri‘s  Vic\v_Manager  c!as.s  provides 
default  funciioiiality.  fully  expecting  that  applications  will  customize  their 
View  management  by  Inheritance.  Window  management  will  probably  be  the 
most  widely  used  reason  for  tailoring  the  View_Manager  class  in  applications, 
as  each  View  has  Its  own  window  in  the  display.  The  View^Manager  class  will 
also  administer  interactions  between  input  devices,  because  user  input  is 
commonly  obtained  from  windows  through  the  operating  system. 

Finally,  the  Simulation  class  serves  as  the  focal  point  of  an  application, 
defining  how  its  different  pieces  interact  and  providing  executive  control 
over  the  program.  A  Simulation  subclass  must  first  define  the  Environment, 
Players,  and  Views  that  it  uses,  as  well  as  the  dissociations  that  interconnect 
them.  A  subclass  must  provide  initialization  techniques  for  its  attributes  and 
ensure  that  each  piece  of  the  simulation  is  properly  incorporated  into  the 
application's  scheme.  Finally,  a  Simulation  subclass  must  supply  the  algo¬ 
rithms  that  define  the  interaaions  among  its  attributes  during  the  simulation. 

This  chapter  has  outlined  the  development  of  one  application  and  de¬ 
scribed  the  general  techniques  used  to  inherit  from  the  Easy_Sim  framework 
to  create  an  application.  The  next  chapter  looks  at  the  different  versions  of 
the  Easy^Sim  and  ObjertSlm  frameworks,  and  draws  results  from  their  compar- 


VI  Results  and  Comparisons 

This  chapter  presents  an  analysis  of  the  different  versions  of  the  ObjectSim 
and  Easy_Sim  application  frameworks.  The  data  contained  here  shows  the  suc¬ 
cess  of  this  research  effort  by  demonstrating  that  a  visual  simulation  system 
software  architeaure  can  be  implemented  with  an  Ada  9X  application  frame¬ 
work  so  that  it  provides  capabilities  comparable  to  a  similarly  designed  C+- 
framework. 

The  first  section  of  this  chapter  covers  background  material  and  com¬ 
pares  two  performance  measurements,  frame  rate  and  application  thread  lime. 
The  second  section  shows  the  different  sizes  of  the  executable  prog  rams.  The 
final  portion  of  the  chapter  examines  differences  in  language  features  be¬ 
tween  the  Ada  9X  and  C++  versions  of  the  Easy_Sim  framework. 

6.1  Performance  Comparisons 

The  most  important  performance  measurement  in  any  visual  simulation  sys¬ 
tem  Is  its  frame  rare,  or  the  number  of  Individual  screen  images  the  simulation 
displays  per  second.  This  number  indicates  the  realism  portrayed  to  the  53^5— 
tern's  users,  as  the  illusion  of  motion  tricks  the  human  eye  when  individual 
frames  are  presented  in  rapid  succession.  If  the  frame  rate  becomes  too  slow, 
the  view'er  begins  to  notice  individual  frame  boundaries,  a  phenomeno.". 
knowm  as  Jirrer. 

The  frame  rate  considered  adequate  for  a  simulation  depends  on  the 
purpose  of  the  simulation  system,  the  expectations  of  its  user,  and  the  method 
of  display.  A  person  being  entertained  demands  total  realism,  while  trainees 
tolerate  some  jitter  in  order  to  accomplish  their  objectives.  Additionally,  the 
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consequences  of  jitter  are  multiplied  if  th?  vipvjpr?  in 
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display,  as  the  stability  offered  by  their  peripheral  vision  is  absent. 

Taking  these  variables  into  account,  jitter  becomes  noticeable  near 
thirty  frames  per  second.  The  ideal  frame  rate  for  simulations  is  sixty  frames 
per  second,  the  rate  at  which  most  televisions  operate.  The  AFIT  Graphics  Lab 
considers  twelve  to  fifteen  frames  per  second  acceptable  for  its  simulations,  as 
the  users  accept  some  inaccuracy  in  a  research  environment.  This  rate  varies 
somewhat  depending  on  the  t\'pe  of  viewing  device  used. 

This  research  effort  used  functions  provided  by  SGI's  Performer  library’ 


to  gather  and  display  performance  statistics.  The  data  collected  includes  the 
frame  rate  and  the  time  spent  per  frame  In  each  of  the  application,  cull,  and 
draw  threads  (see  Section  2.4).  Because  an  application  is  only  rendered  as  fast 
as  Us  slowest  process,  the  thread  times  are  important  in  determining  if  one 
process  impedes  the  entire  application.  .Analysis  of  the  application  thread 
shows  the  differences  among  the  different  versions  of  the  implementation, 
because  the  application  developer's  code  is  executed  in  this  thread.  By  default, 
Performer  executes  the  cull  and  draw  threads  on  its  own. 

A  simple  application,  like  the  Circling  Planes  described  in  Chapter  V,  is 
draw  limited,  meaning  that  the  draw  thread  takes  much  longer  to  execute  than 
either  the  application  or  cull  thread.  The  complex  models  used  to  represent 
the  Planes  and  Terrain,  contrasted  with  the  simple  movement  of  the  Planes, 
account  for  this  difference.  Most  applications  are  application  limited,  how¬ 
ever,  as  the  reproduction  of  realistic  Player  behavior  Is  often  quite  intricate. 
The  Space  Modeler  [Van94],  for  instance,  models  the  movement  of  planets  and 
stars,  and  performing  the  corresponding  calculations  each  frame  is  many 


times  more  computationally  expensive  than  lighting  the  small  areas  on  the 
screen  that  represent  these  objects  graphically. 

Throughout  the  development  of  the  Easy_Sim  application  framework, 
much  of  the  complex  functionality  of  ObjectSim  was  net  transferred.  These 
features  all  contribute  to  the  ObjectSim  framework,  but  they  are  not  essential 
in  the  production  of  a  visual  simulation.  Unfortunately,  the  two  frameworks 
cannot  be  compared  fairly  with  this  differing  functionality.  Anticipating  this 
divergence,  a  C+-  version  of  the  Easy_Sim  architecture  was  maintained  to 
parallel  the  Ada  9X  version.  A  comparison  between  these  two  versions  of  the 
Easy_Sim  framework  Is  made  later  in  this  chapter. 

The  tests  gathering  performance  statistics  were  undertaken  on  a  four- 
processor  SGI  Ony'x/Realizy  Engine^  machine  running  at  150  megahertz.  The 
tests  were  conducted  under  controlled  conditions,  with  one  user  logged  into 
the  machine,  and  two  open  winierm  windows.  The  application  window  was 
opened  to  full  screen  size  to  maximize  the  rendering  area  and  provide  consis¬ 
tency  for  each  test.  The  machine  uses  version  5.2  of  the  IRIX  operating  sys¬ 
tem.  Both  the  Ada  9X  and  C++  versions  of  the  application  framework  were 
compiled  with  maximum  optimization. 

6.1.1  Frame  Rate  Comparisons 

The  implementation  of  Easy_Sim  was  originally  tested  by  reproducing  the  first 
two  ObjectSim  example  applications  lSny93,AppA]  with  both  Easy_Sim  and  Ob¬ 
jectSim.  How'ever,  because  these  examples  are  draw  limited,  and  the  ObjectSim 
and  Easy_Sim  implementations  render  the  same  scenes,  the  frame  rates  match 
exactly.  These  tests  were  therefore  inconclusive,  and  computationally  expen¬ 
sive  applications  were  devised  to  provide  a  better  comparison. 
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These  new  applications  were  based  on  the  Circling  Planes  example,  and 
merely  prolonged  Its  application  thread  by  increasing  the  number  of  aircraft. 
This  expansion  resulted  in  a  simulation  in  which  multitudes  of  planes  fly 
routes  whose  paths  resemble  the  overlapping  rings  of  the  Olympic  flag.  The 
number  of  planes  in  the  formation  was  first  expanded  to  10,  then  to  100,  400, 
and  1,000. 

Each  of  these  simulations  can  be  viewed  from  three  locations:  the  sec¬ 
ond  plane  on  one  end  of  the  formation,  the  last  plane  on  the  other  end,  or  the 
tracker  who  observes  from  afar.  When  viewed  from  the  tracker,  an  intimidat¬ 
ing  line  of  planes  moves  across  the  screen.  Unfortunate!}’,  this  angle  does  not 
provide  any  better  comparison  data,  because  drawing  the  entire  formation  is 
still  more  costly  than  moving  it.  If  the  view  is  moved  to  one  of  the  planes,  the 
desired  effect  Is  achieved.  From  these  angles,  the  plane  cycles  through  points 
where  the  attached  view  sees  all  the  other  planes  aligned  and  point.?  w-here  it 
sees  no  other  planes.  The  first  case  remains  draw  limited,  because  rendering 
all  of  the  planes  is  still  arduous.  However,  the  second  case  is  application  lim¬ 
ited,  as  the  simulation  still  performs  calculations  to  m.ove  the  planes  even 
when  they  are  hidden  from  view. 

Given  these  standard  applications,  tests  were  run  using  both  the  Ada  9X 
and  C+-  versions  of  the  Easy_Sim  implementation.  ObjectSim  was  also  tested  as 
a  baseline  reference  point,  even  though  its  differing  C —  functionality  pre¬ 
vented  a  truly  fair  comparison.  Table  2  shows  the  test  results.  For  each  of 
these  frameworks,  data  was  gathered  on  the  four  different  quantities  of  air¬ 
craft.  The  first  row  for  each  framework  shows  the  application  limited  test, 
when  all  planes  are  mo\ing  but  none  are  being  shown.  The  second  row  for 


Table  2.  Frame  Rates  for  Circling  Planes  Simulations 


Architecture/ 

Language 

Planes 

Seen 

Plane  Positions  Being  Updated  ! 

10^ 

100 

400 

1000 

Easy_Sini/ 

Ada9X 

none 

30 

30 

30 

10 

all 

20 

12 

4.0 

wm 

Easy_Sim/ 

C++ 

none 

30 

30 

30 

10 

all 

20 

12 

3.8 

1.6 

ObjectSim/ 

C++ 

none 

wm 

30 

30 

m 

all 

20 

15 

3.8 

B  (Frames  per  second)  1 

each  framework  shows  the  draw  limited  case,  when  all  planes  are  moving  and 
being  drawn. 

These  results  are  remarkable  because  they  suggest  that  there  is  no  sig¬ 
nificant  difference  in  the  performance  of  the  three  versions  at  given  levels  of 
stress.  Most  Important  is  the  direct  comparison  between  the  Ada  9X  and  C— i- 
versions  of  Easy.Sim,  which  have  mirror*!ike  implementations  (see  Section 
6.3).  The  results  demonstrate  that  the  use  of  the  Ada  9X  language  itself  does  not 
hinder  the  rendering  of  a  visual  simulation.  The  gathering  of  evidence  that 
the  Ada  9X  version  of  Eaiy_Sim  performs  at  a  level  comparable  to  the  sam.e 
application  built  in  C++  succeeds  in  satisfying  one  of  the  main  goals  of  this 
thesis  effort. 

The  next  section  examines  a  more  specific  aspea  of  the  perform.ance  by 
focusing  on  the  application  thread  times  of  the  Circling  Planes  simulation. 
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6.1.2  Application  Thread  Time  Comparisons 

While  Table  2  above  shows  that  the  botrom  line  performance  of  the  Ada  9X 
Easy_Sini  framework  is  similar  to  both  the  ObjectSim  and  nasy_Slni/C-i--i-  Vcr* 
sions,  the  frame  rate  encompasses  the  execution  limes  of  al!  three  of  the  Per¬ 
former  threads  (see  Section  2.4).  It  is  only  the  application  thread,  however 
that  illustrates  the  differences  between  thn  different  versions  of  the  Circiini.: 
Planes  application,  because  Performer  executes  the  overwhelming  majority  of 
the  cull  and  draw  threads.  Table  3  shows  the  applicatioi.  thread  times  per 
frame  for  the  Circling  Planes  applications.  Because  the  application  thread 
time  does  not  depend  on  the  view,  only  one  row  is  necessary'  for  each  version 
of  the  application  framework. 

Table  3  clearly  shows  the  performance  difference  of  the  Ada  9X  code, 
which  runs  25%  slower  than  the  corresponding  C-+  cede.  This  extra  process¬ 
ing  is  expected,  and  can  mainly  be  attributed  to  the  immaturity  of  the  GN.^T 
compiler.  Just  like  this  thesis,  the  GNAT  team's  first  objeaive  Is  to  produce 
working  code,  with  optimization  a  secondary  long  term  goal.  In  fact,  no  work 
at  all  has  been  done  on  Ada  specific  optimizations  lDew94b].  Given  this  state¬ 
ment,  the  fact  that  the  code  is  only  25%  behind  is  remarkable.  Furthermore, 
given  that  the  bottom  line  performance  of  the  simulation  is  equivalent  with 


Table  3.  Application  Thread  Times  for  Olrcling  Planes  .Si ■nu! aliens 


Plane  Positions  Lelne  Undated  1 

Archltecture/Language 

io 

100 

400 

1000 

Easv_Sim/Ada  9X 

1.7 

8.5' 

31 

75 

Easv_Slm/C++ 

1.4 

6.5 

25 

60 

Ob)ectSlm/C++ 

7.1 

11.4 

26 

61 

(Milliseconds  per  Frame) 
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Che  compiler  in  this  state,  the  future  looks  very  bright  for  Ada  9X  in  the  simu¬ 
lation  industiy'. 

Another  common  factor  in  the  slower  running  of  Ada  code  is  the  run¬ 
time  checking  associated  with  exception  handling.  The  Ada  9X  application 
framework  for  Easy_Sim  follows  the  Ada  mindset  of  using  exception  handling 
to  make  the  code  more  reliable  and  easier  to  test,  and  this  programming  style 
greatly  eased  the  development  of  the  Easy_Sim  framework.  Regardless,  the 
Circling  Planes  test  cases  were  recompiled  with  the  run-tirne  checks  sup¬ 
pressed  to  see  how  it  would  affea  the  performance  of  the  code.  Surprisingly, 
the  elects  were  minimal.  Once  again,  however,  the  compiler  developers 
blame  this  behavior  on  the  immaturity  of  their  product.  Because  the  checks  in 
the  run-time  system  of  version  1.83  have  not  been  suppressed,  suppressing  the 
checks  in  a  source  program  will  not  affea  its  performance.  This  hindrance 
has  been  removed  from  version  2.00  [San94]. 

The  ObjectSim  row  of  Table  3  is  interesting  for  two  reasons.  Somewhere 
ObjeaSim  incurs  processing  overhead  in  its  applications,  most  likely  because 
of  its  use  of  shared  memory.  Using  this  Performer  feature  is  costly  for  s.ma!! 
applications,  but  the  initial  investment  is  returned  when  the  simularion  be¬ 
comes  complex.  The  test  results  also  demonstrate  that  the  efficiency  suppos¬ 
edly  gained  by  ObjectSim’s  rejecting  encapsulation  and  relying  on  global  ac^ 
cess  is  not  perceptible,  as  both  C-^+  frameworks  slow  at  an  equal  rate  when  the 
processing  load  is  Increased.  This  result  is  welcome  news  for  supporters  of  the 
software  engineering  discipline.  Programmers  in  performance  critical  soft¬ 


ware  fields  have  often  dismissed  the  principles  of  software  engineering  by 
citing  efficiency  concerns,  but  these  results  indicate  that  similar  efficienc>' 
can  be  attained  when  following  a  well-planned,  encapsulated  design.  Just  as 
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the  Immaturity  of  the  GNAT  compiler  can  be  b’-amed  for  the  slowness  of  the 
Ada  code,  the  maturity  of  tha  optimization  techniques  of  the  ATdrT  C++  compiler 
can  be  thanked  for  unraveling  encapsulation  on  the  machine  code  end. 

The  performance  issues  analyzed  in  this  section  strongly  suggest  that 
Ada  9X  can  perform  alongside  the  C-based  languages.  Ada’s  shortcomings  in 
the  application  thread  time  are  well  worth  the  development  headaches  it 
avoids.  This  notion  is  especially  true  considering  that  the  bottom  line  perfor¬ 
mance  is  not  affected  and  future  gains  in  compiler  optimizations  are  assured. 
The  next  seaion  also  anal>'zes  an  area  in  which  .Ada  is  notorious-code  size, 

6.2  Executable  Size  Comparisons 


With  the  constantly  expanding  space  available  on  today’s  computer  systems, 
the  importance  of  program  size  is  waning  rapidly.  However,  this  section 
quickly  examines  the  issue  for  a  complete  ?na!ys!S. 

Ada  programs  have  traditionally  been  larger  than  C  and  C-r  programs. 
The  reasons  for  this  dilemma  included  difficulty  in  optimizing  the  complexity 
of  the  language  features,  the  run-tim.e  checking  mentioned  above,  and  the 
inclusion  of  large  libraries  for  such  tasks  as  input  and  output.  Recently,  Ada 
83  compiler  maturity  has  alleviated  this  problem  (Law923. 


Table  4  shows  the  sizes  of  the  executable  files  for  the  Circling  Planes 
example  programs.  Because  the  different  versions  of  Circling  Planes  only 
vary  In  the  length  of  an  array,  the  10, 100,  400.  and  1,000  plane  versions  are  all 


virtually  the  same  size.  Generally,  the  Ada  9X  vcrsicr.s  are  just  unde.'-  r.vice  as 


large  as  the  C++  versions. 
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Table  4.  Sizes  of  Execuiable  Code  for  Grdir.®  Plar.es  Simulations 


Architecture  i 

Language 

Features  i 

Mmm 

Easy_Slm 

Ada  9X 

Optimized,  Inlined 

1186 

Easy»Sim 

Ada  9X 

Optimized 

1185 

Easy..Sim 

Ada  9X 

Totally  Regular 

1189 

Easy_Sim 

Ada  9X 

Inlined 

1211 

Easy_Slm 

Ada  9X 

Optimized,  Inlined, 
Suppressed 

1164 

Easy_Slm 

Ada  9X 

Optimized,  Inlined, 

No  Text_IO 

1174 

Easy^lm 

C++ 

Optimized,  Some  Inllning 

703 

ObjectSim 

C++ 

Optimized,  Some  Inllning 

666 

The  table  shows  six  different  versions  of  the  Ada  9X  examples,  showing 
experimentation  with  different  compilation  options.  The  version  whose  per¬ 
formance  statistics  were  presented  in  the  last  section  Is  the  inlined  and  opti¬ 
mized  version,  shown  at  the  top.  The  inlining  was  applied  to  the  Get  and  Set 
operations,  as  described  in  Section  4.3.  Varied  compilation  options  were  ana¬ 
lyzed  originally  because  the  AT&T  C--  compiler  would  not  support  inlining  to 
the  extent  of  the  GN.AT  compiler.  To  ensure  that  the  Ada  version's  more 
prominent  use  of  Inllning  did  not  sway  the  results,  the  application  framework 
was  rewritten  without  using  the  Inline  pragma,  and  all  four  tests  were  run 
again.  No  appreciable  differences  were  found  in  the  performance  of  the  non- 
Inlined  version,  and  the  size  of  the  code  remained  virtually  the  same. 

This  result  is  slightly  surprising,  but  it  is  more  understandable  when 
the  maturity  of  the  compiler  is  again  considered.  The  machine  code  optimiza¬ 
tion  of  the  established  GNAT  gcc  back  end  is  mature  enough  to  automatically 
inline  the  simplistic  calls  within  the  same  module.  However,  the  GNAT  1.83 
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front  end  has  not  yet  tackled  ir.Mning  across  package  boundaries  [Pew94a1. 
Therefore,  the  optimization  originally  intended  by  the  use  of  the  pragma  was 
never  being  completely  realized.  The  pragmas  are  therefore  redunuant  when 
the  compiler’s  optimization  techniques  are  employed,  as  the  data  In  the  first 
two  rows  of  Table  4  indicates. 

A  more  normal  Increase  in  the  size  of  the  inlined  version  is  evident  in 
the  fourth  row  of  the  table,  when  optimization  is  not  used.  As  expected,  the 
performances  of  the  versions  run  without  optimizatic:  are  a  notch  slower 
than  their  optimized  counterparts.  The  application  thread  time  of  the  non-op- 
timized  Inlined  Ada  9X  version  runs  8S  milliseconds  for  1.000  circling  planes, 
as  compared  with  71  milliseconds  when  optimized.  This  ext- a  time  translates 
into  a  frame  rate  of  8.6,  instead  of  the  optimized  version’s  10  frames  per  sec¬ 
ond. 

Additional  data  was  collected  on  two  other  versions  of  the  Easy„Sim 
framework  running  the  Circling  Planes  tests.  The  first  was  compiled  with  all 
run-time  checks  suppressed.  This  version  lessened  the  code  by  22  kilobytes,  or 
296.  Removing  the  use  of  the  TextJO  and  thereby  all  of  the  information  di.s* 
played  on  the  console  removed  12  kilob>'tes  from  the  code  size. 

Because  of  the  lessening  importance  on  code  size,  this  problem  ha ;  been 
a  very  low  priority  for  the  GN.^T  developers.  They  do  plan,  however,  to  use 
d3'namic  linking  sometime  in  the  future.  Because  this  technique  "can  make  a 
significant  difference,"  the  potential  does  exist  for  GNAT  to  become  more  com¬ 
petitive  w'ith  the  C  languages  in  the  arena  of  cods  size  [Com94]. 

The  next  section  discusses  the  similarities  and  differences  between  the 
Ada  9X  and  C-+  implementations  of  the  Easy_Sim  application  framework. 


131 


6.J  Language  Comparisons 


As  shown  throughout  this  chapter,  a  C++  version  of  the  Easy_Sirn  application 
framework  was  maintained  with  the  same  functionality  as  the  Ada  9X  version, 
so  that  objective  performance  comparisons  cctild  be  made  between  the  two 
languages.  This  section  compares  and  contrasts  the  more  subjeaive  features 
of  the  languages  themselves. 

The  C++  version  of  the  E  ’sj'_Sim  framework  was  constructed  to  match 
the  Ada  9X  version  as  closely  as  possible,  again  to  provide  a  fair  performance 
comparison.  While  this  approach  seems  like  it  would  neglect  important  fea¬ 
tures  of  C++  design,  the  two  languages  have  actually  converged  so  closely  that 
the  major  object-oriented  features  of  C-+  are  em.ployed  heavily,  In  other 
words,  a  C++  implementation  of  the  Easy_Sim  software  architecture  developed 
straight  from  the  design  would  look  almost  identical  to  the  version  produced 
by  translating  the  Ada  9X  implementation. 

Each  class  package  in  Ada  9X  became  a  class  In  C+-,  with  constructors, 
destructors,  a  Configure  function,  and  various  virtual  functions.  The  private 
parts  of  the  Ada  code  were  generally  placed  in  the  class  header's  protected 
section,  so  that  they  could  be  accessed  by  client  programmers  deriving  sub¬ 
classes.  Ada  9X's  child  packages  were  brought  to  the  top  level  in  C++.  The  rest 
was  generally  translated  construct  for  construct,  in  a  ver}'  straightfcnvard 
manner,  so  that  the  frameworks  ended  extremely  similar.  The  rest  of  this  sec¬ 
tion  points  out  the  minor  differences  that  arose. 

Just  like  GMAT,  the  AT&T  C++  compiler  would  not  allow  sll  supposedly  le¬ 
gal  constructs  within  the  language  to  be  implemented.  As  alluded  to  in  the 
previous  section,  the  compiler  would  not  allow  inlining  within  the  source 
files.  The  C++  compiler  also  did  not  support  the  language's  new  exception 
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handling  mechanisms,  and  the  locations  in  the  Ada  9X  code  where  exceptions 
are  used  were  implemented  with  conditional  statements.  Finally,  the  Ct+ 
compiler  had  problems  discerning  different  uses  of  the  same  identifier.  In  the 
Ada  version,  a  Get  function  returning  a  class  variable  generally  bears  the 
name  of  that  class.  The  C+-i-  compiler  was  confused  by  this  ambiguity,  however, 
and  Get  was  therefore  included  explicitly  in  the  names  of  all  the  Get  functions. 

While  the  unimplemented  features  of  C++  weri'  impossible  to  use,  those 
features  that  were  Implemented  are  often  more  complicated  than  their  Ada 
counterparts.  Parameter  passing  Is  one  of  these  cases.  Because  Ct+  stores  ar¬ 
rays  as  constant  pointers,  a  function  cannot  return  an  array  value.  This  limi¬ 
tation  caused  all  of  the  Get  operations  for  the  Positions  and  Directions  to  be 
implemented  as  void  functions  where  the  array  In  which  the  value  was  to  be 
placed  is  passed  by  reference  as  an  argument.  This  inconsistency  in  handling 
types  causes  the  uniformit)’  of  the  C-+  version  to  suffer.  Both  .Ada  and  C-+  al¬ 
low  parameters  to  have  default  values,  but  this  feature  is  easier  to  use  in  Ada. 
Because  the  use  of  named  notation  in  Ada  parameter  passing  allows  specifica¬ 
tion  of  actual  parameters  In  any  order,  not  ever)'  parameter  needs  to  be  passed. 
C++  only  allows  the  last  parameters  In  a  function’s  argument  list  to  be  skipped. 
This  rule  does  not  allow  a  client  programmer  to  use  the  default  value  for  the 
second  last  argument  and  provide  a  value  for  the  last  argument.  Many  of 
Easy_Slm's  Configure  operations  are  designed  so  that  only  one  or  two  parame¬ 
ters  of  six  or  seven  need  be  specified,  but  this  design  will  not  work  In  C-+ 
given  certain  combinations  of  arguments.  The  C+-  programmer  will  therefore 
have  to  provide  values  for  variables  she  would  rather  ignore. 

The  Configure  operation  is  one  aspea  of  the  Easy_Sim  architectural  de¬ 
sign  that  might  be  implemented  differently  in  C++.  Because  constructofs  in 


c*+  can  have  arguments,  some  of  the  Configure  operations  could  be  performed 
as  overloaded  constructors.  However,  many  of  the  parameters  to  Configure  are 
not  known  when  the  object  is  created,  so  some  of  the  Configure  operations 
would  still  have  to  be  explicitly  called  after  construction.  In  order  to  maintain 
consistency  throughout  the  architecture,  therefore,  the  solution  used  in  the 
Ada  9X  version  is  also  the  better  solution  in  C+-. 

Controlled  operations,  Ada's  counterpart  to  default  constructors  and  de¬ 
structors,  also  contain  the  Adjust  procedure,  whose  functionality  is  absent  in 
the  C+-r  model.  Adjust  is  used  so  that  a  client  programmer  can  explicitly  con¬ 
trol  assignment  between  two  variables  (see  Seaion  2.1.2).  The  Ada  BX  Easy_Siui 
application  framework  uses  the  .Adjust  procedure  to  conveniently  clone  dif¬ 


ferent  models,  as  this  operation  is  called  automatically  when  a  model  is  as¬ 
signed  to  another.  The  C-+  version  requires  the  explicit  call  of  the  Clone  op¬ 
eration. 

Lest  it  appear  that  this  section  is  too  Ada  biased,  the  final  feature  dis¬ 
cussed  is  easier  to  use  in  C+-.  Ada  9X  package  specifications  have  kept  to  the 
original  Ada  design  of  a  public  and  private  part.  If  the  attributes  of  a  class  are 
encapsulated  privately,  they  are  not  automatically  visible  within  derived  sub¬ 
classes.  If  a  child  class  would  like  access  to  the  private  part  of  its  parent,  it 
must  be  declared  inside  a  hierarchical  library'  unit  that  is  a  child  of  the  class 


package.  This  model  is  not  always  desirable,  however.  First,  private  parts  are 
no  longer  that  private.  Second,  the  components  of  the  Easy_Sim  framework 
are  all  defined  to  be  part  of  the  Easy.Slm  package,  and  application  developers 
are  encouraged  to  derive  subclasses  of  the  Easy_Sim  components  in  their  own 
packages.  The  subclasses  therefore  do  not  have  access  to  their  parent's  at¬ 
tributes  (see  Section  5.1.3).  Protected  parts  of  C-(-+  header  files  solve  this 
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dilemma  by  specifying  that  subclasses  are  allowed  visibility  of  the  parent's 
member  data.  This  model  is  much  cleaner  and  preserves  the  privacy  model 
necessary  to  ensure  proper  encapsulation. 

This  chapter  has  compared  the  different  versions  of  the  Easy„Sim  appli¬ 
cation  framework  by  analyzing  both  performance  and  language  issues.  The 
next  chapter  concludes  this  research  effort  and  suggests  areas  of  focus  for 
future  studies. 
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VII  Conclusions  and  future  Study 

The  development  of  Eas)'_Sim  has  improve;  the  ObjectSim  software  architec¬ 
ture  for  visual  simulation  systems  and  been  instrumental  in  showing  that  the 
object-oriented  features  of  Ada  9X  can  compare  with  their  counterparts  in  C+t. 
There  is  still  much  more  potential  for  these  languages  to  work  together,  as 
well  as  for  the  added  benefits  of  Ada  9X  to  be  realized.  This  chapter  re\iews  the 
accomplishments  of  this  thesis  effort,  makes  suggestions  for  areas  of  future 
study,  and  outlines  methods  for  the  reader  to  obtain  more  information  on 
Easy_Sim. 

7.1  Easy_Sim  and  Its  Accomplishments 

Easy_Sim  is  both  a  software  architecture  and  an  application  framework  realiz¬ 
ing  that  architecture.  .At  the  design  level,  Easy_Sim  follows  the  object-ori¬ 
ented  data  abstraction  model  defined  by  Garlan  and  Shaw  [Garl93.7-8]  (see  Sec¬ 
tion  2.2).  Easy«Sim  provides  the  structure  by  which  developers  can  create 
their  applications,  allowing  them  to  exploit  a  proven  basic  design  and  behav¬ 
ior  for  their  systems. 

Easy.Sim  improves  upon  its  predecessor,  ObjectSim,  in  many  ways. 
Where  ObjectSim  tried  to  present  a  coherent,  encapsulated,  and  consistent  de¬ 
sign,  It  fell  prey  to  productivity  demands.  The  result  was  a  framework  that  is 
difficult  to  understand,  arduous  to  use,  and  troublesome  to  modify.  Without  the 
pressure  of  dependent  projects,  Easy_Sim's  architecture  was  able  to  evolve  into 
the  design  that  was  envisioned  for  ObjertSim.  Dr,  Jean  Ichbiah,  the  original 
architect  of  Ada,  has  said,  "I  am  driven  by  aesthetic  considerations  and  the 
strong  belief  that  only  beautiful  shape  can  be  correct  shape"  llch92]. 
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Easy.Sim  follows  this  tenet,  and  creates  an  evenly  formed  architecture  and 
implementation  whose  consistency  throughout  differing  levels  of  abstraction 
breeds  simplicity  and  ease  of  use. 

This  thesis  effort  has  produced  more  than  just  aesthetically  pleasing 
code,  however.  By  backing  up  the  architecture  with  data  demonstrating  the 
framework’s  production  of  efficient  applications,  Easy_Sim  has  shown  that 
good  designs  can  also  be  successfully  implemented.  Better  yet,  Easy_Sim.  has 
displaj'ed  this  concept  in  the  graphics  field,  a  discipline  which  historically 
has  shunned  software  engineering  principles  under  the  auspices  of  effi¬ 
ciency'.  Hopefully  Easy_Sim  has  made  Inroads  that  Will  not  ww  fcrgctten* 

Easy^Sim  has  also  been  one  of  the  seminal  object-oriented  projects  to  be 
implemented  in  Ada  9X.  Many  of  the  concepts  originally  thought  to  be  trivial 
in  the  language  proved  more  complex  when  scaled  to  a  project  the  size  of 
Easj'_Sim.  The  lessons  learned  from  Easy.Sim  have  already  contributed  to  the 
object-oriented  Ada  community,  and  hopefully  further  Easy_Sim  development 
will  continue  this  trend. 

7.2  Suggestions  for  Future  Study 

Although  the  Easy_Slm  architecture  and  framework  have  succeeded  in  attain¬ 
ing  their  preliminar>’  objectives,  work  remains  lo  further  their  development. 
Many  features  Implemented  In  ObjectSim  were  not  carried  into  Easy_Sim,  and 
no  m'  cries  have  been  collected  to  quantify  the  quality  of  either  system.  Both 
the  architecture  and  framework  of  Easy_Sim  could  benefit  from  the  develop¬ 
ment  of  a  large  scale  application  to  test  the  varying  uses  of  Easy_Sim  classes 
proposed  in  Section  5.2.  If  successful,  this  project  could  serve  as  an  example 
throughout  the  object-oriented,  graphics,  simulation,  and  Ada  communities. 
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The  following  discussion  of  the  areas  for  future  work  is  broken  into  two 
sections.  The  first  section  outlines  the  architeaural  issues  to  investigate,  and 
the  second  section  lists  areas  in  which  improving  the  implementation  would 
be  beneficial. 

7.2.1  Architectural  Improvements 

Many  ideas  that  were  entertained  during  the  evolution  of  the  £as>'_Sim  design 
were  never  realized,  as  the  primarv’  effort  was  focused  on  producing  and  eval¬ 
uating  a  working  system.  Now  that  this  endeavor  has  been  accomplished, 
there  is  room  to  go  back  to  the  simulator  industry  and  conspire  to  produce  an 
architecture  that  defines  the  industry  standard  and  Is  independent  of  the  SGI 
platform.  Individuals  throughout  the  commercial  sector  have  already  ex¬ 
pressed  interest  in  helping  to  attack  this  problem. 

As  many  techniques  for  general  Easy^Sim  application  development 
have  been  proposed  in  this  thesis  (see  Section  5.2),  components  need  to  be 
built  to  examine  the  feasibility  of  these  techniques.  For  instance,  is  the 
Player...Manager  class  the  right  place  to  incorporate  collision  detection  or 
network  management  capabifties?  The  construaion  of  an  Easy_Sim  applica¬ 
tion  can  validate  this  question.  The  remainder  of  this  section  proposes  specific 
areas  of  the  Easy_Sim  architecture  where  improvements  can  be  made  or  alter¬ 
native  designs  studied. 

There  are  two  areas  in  which  the  Vlew_Manager  needs  to  be  analyzed 
further.  Because  Views  provide  a  method  of  looking  into  a  sce.ne,  they  ZTt  of¬ 
ten  associated  with  display  windows.  Realizing  this,  an  attempt  was  made  to 
move  the  Open_VVlndow  operation  from  the  Simulation  class  to  the 
View_Manager,  but  an  inexplicable  compiler  bug  prevented  the  completion  of 
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this  architectural  change.  This  preferred  stmcture  should  be  reassessed  a? 
the  compiler  matures.  The  Vie\v_Manager  class  also  supports  multiple  View 
management,  but  this  feature  has  not  been  tested  by  an  application.  Perform¬ 
ing  these  tests  can  validate  the  mode!  upon  which  the  multiple  View  synnort  js 
based. 

Another  manager  class,  the  Player_Manager,  also  has  yet  to  be  tested  to 
the  extent  of  its  design.  In  Sections  3.7  and  5.2,  it  was  suggested  that  the 
Player_Manager  ser\'e  as  the  basis  for  collision  detection  and  distributed  in¬ 
teractive  simulation  (DIS)  communication  for  an  application.  Like  the  multi¬ 
ple  Views,  these  design  concepts  also  still  need  to  be  validated  by  demonstra¬ 
tion. 

Although  it  was  not  mentioned  In  Section  3.3,  the  ObjectSim  Fli_Model 
class  provides  mechanisms  to  convert  a  FluModel  established  for  the  DIS  co¬ 
ordinate  systems  so  that  they  are  compatible  with  Performer's  coordinate  sys¬ 
tem.  While  this  functionality  is  necessary  and  useful  for  DIS  applications, 
Easy«Sim  endeavors  to  place  it  inside  a  subclass  of  the  Model  class  instead  of 
the  Model  itself.  This  approach  allows  an  application  developer  tp  avoid  the 
extra  overhead  If  they  do  not  require  DIS  capabilities,  but  provides  a  useful 
class  If  thej'  do  want  to  use  it.  Once  again,  a  demonstration  application  can  be 
developed  to  show  off  the  capabilities  of  the  framework. 

The  model  used  for  handling  user  input  within  the  Easy_Slm  framework 
is  based  on  ObjectSim  and  performed  in  the  Modifier  class.  However,  there  is 
no  reason  that  the  input  need  be  associated  only  with  the  View  class,  as  the 
Modifier  is  intended.  Players  also  need  a  standardized  component  with  con¬ 
nectors  to  provide  a  common  method  for  steering  entities  within  a  simulation. 
With  this  idea  in  mind,  a  standardized  model  for  input  should  be  developed. 
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taking  into  account  that  input  can  affect  control  of  a  View,  control  of  a  Player, 
or  control  of  the  Simulation  itself.  The  most  likely  solution  would  be  to  provide 
a  new  Input  class,  through  which  the  Modifiers  could  determine  the  user’s 
Intentions  and  pass  the  consequence  of  the  inpur  to  Views  or  Players.  The 
Simulation  class  could  access  the  Input  class  directly  to  control  the  application. 
Suggestions  for  the  implementation  of  this  idea  are  developed  further  in  the 
next  sealon. 

There  are  a  couple  of  other  design  areas  that  may  be  implementation  is¬ 
sues.  but  they  are  proposed  briefly  here.  First,  the  Configure  operation,  which 
is  used  by  Easy_Slm  to  provide  parameterized  initialization,  was  originally 
employed  because  controlled  operations  in  Ada  9X  do  not  allow  parameters 
other  than  the  controlled  type  itself.  Some  recent  ideas  have  been  put  forth 
that  propose  to  trick  the  compiler  into  allowing  parameterization,  however 
IKem94].  These  proposals  should  be  evaluated  to  see  if  they  might  enhance 
both  the  Easy_Sim  design  and  implementation.  Second,  Easy_Sim  currently 
has  no  provisions  for  multiple  Performer  Pipes,  each  of  which  represents  a 
multiprocessing  system  for  the  Performer  threads.  Providing  the  capability 
within  the  Easy_Slm  architecture  to  support  this  capability  opens  an  avenue 
for  limitless  expansion  of  computing  power,  as  the  hardware  for  visual  simu¬ 
lations  CO  exploit  continually  advances. 

Having  provided  numerous  areas  in  which  improvements  In  the 
Easy_Sim  software  architecture  might  occur,  discussion  now  focuses  on  aspects 
of  the  Easy_Sim  implementation  that  might  be  improved,  Roth  Performer  and 
Ada  9X  issues  are  presented. 
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7.2.2  Implementation  Improvements 


Just  as  the  design  of  Easy_Sim  could  benefit  from  more  in-depth  anal3’ses,  so 
could  the  implementation.  Because  not  a!!  of  the  ObjectSim  functionality  was 
carried  into  Easy^Sim,  migrating  the  rest  of  this  functionality  would  be  a  good 
starting  place  for  enhancing  the  Eas3'_Sim  framework.  These  features  include 
traversal  masks,  Jitter  removal,  shared  memory  use.  and  round  earth  coordi¬ 
nate  utilities.  The  rest  of  this  section  suggests  improvements  to  the  Performer 
and  Ada  9X  aspeas  of  the  code. 

There  are  several  areas  where  the  use  of  Performer  could  be  enhanced 
In  the  Easy_Sim  framework.  The  most  critical  and  probably  most  beneficial  of 
these  is  the  collection  of  user  input.  Currently  this  tack  is  performed  by  GL 
functions.  However,  these  capabilities  will  be  removed  in  the  next  generation 
of  GL,  and  the  current  Performer  documentation  suggests  that  all  user  input 
be  handled  by  X  Windows  utilities  [Har94,321], 

Another  area  for  improved  use  of  Performer  is  the  use  of  a  texture  list  to 
preload  all  of  the  complicated  textures  Into  the  application’s  memory.  If  this 
step  is  not  performed,  each  time  the  simulation  encounters  a  texture  for  the 
first  time,  the  application  halts  while  the  database  Information  for  that  texture 
is  loaded.  This  hiccuping  should  be  avoided  if  possible. 

There  are  areas  where  communication  between  Performer  and  Ada  9X 
must  occur.  The  callback  operations  for  the  cull  and  draw  threads,  as  well  as 
the  window  opening  callbacks,  currently  do  not  have  the  ability  to  access  any 
Ada  variables,  either  through  parameters  or  globally.  For  the  cull  and  draw 
operations,  the  use  of  Performer’s  Passthrough  Data  capabilities  may  solve  the 
problems  (Har94, 140-1 43],  Alternate  solutions  may  be  r.ecezss^ry  for  the  ivi.n- 
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dow  opening  operation,  however.  If  this  solution  works  In  al!  cases-,  then  a 
consistent  approach  should  be  used  throughout  the  entire  framework. 

There  are  some  general  coding  concerns  that  Ada  can  address  in 
Easy.Slm.  The  first  and  perhaps  most  visible  of  these  is  the  repetition  of  the 
coordinate  functions  in  Player.  View,  and  Modifier.  This  massive  code  dupli¬ 
cation  can  be  avoided  through  the  use  of  a  generic  package,  but  may  also  be 
correaed  with  tagged  types.  Either  way  the  coordinates  should  probably  be 
put  in  their  own  package  and  separated  from  the  parent  Easy_Sim  package  in 
which  they  are  currently  declared.  The  use  of  coordinates  might  also  be  en¬ 
hanced  by  the  use  of  subtyping  for  the  heading,  pitch,  and  roll.  This  step  was 
not  carried  out  however,  because  it  is  unclear  that  all  applications  would  want 
to  interpret  these  ranges  similarly.  For  instance,  should  a  pitch  of  91  wrap 
around  to  89  with  the  heading  reversed?  Or  is  it  ail  right  to  have  a  roll  of  4507 
This  change  should  be  carefully  examined  and  justified  if  it  is  undertaken. 

The  Manager  classes  present  a  few  interesting  possibilities  for  code  im¬ 
provement.  Because  they  have  similar  foundations,  it  may  be  possible  to  make 
a  base  generic  package  from  which  they  could  all  be  instantiated.  The  Man¬ 
ager  classes  might  also  be  able  to  profit  from  the  use  of  Ada  9X's  protected 
types,  which  are  a  form  of  monitor  (Bar93,  RM9<?j.  Because  each  class  main¬ 
tains  a  single  list  of  objects,  and  access  to  those  objects  should  be  protected 
against  multiple  access  problems  In  SGl’s  multiprocessor  environments,  the 
Managers  seem  a  perfect  fit  for  this  new  language  construct.  The  manage¬ 
ment  of  the  View  states  in  the  View  Manager  Is  rather  complicated,  and  may 
stand  to  be  split  from  the  rest  of  the  class.  Because  the  application  developer 
would  have  no  reason  to  access  this  class  package,  it  could  be  implemented  as  a 
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private  package  visible  only  within  the  Easy_Sirn  application  framework  hier¬ 
archy. 

Possible  design  changes  for  the  handling  of  user  input  were  proposed 
above.  Better  solutions  for  the  implementation  of  this  area  of  the  program  are 
also  needed.  In  the  current  design  user  input  is  recorded  in  flags  contained  in 
Modifier  subclasses,  and  these  flags  are  accessed  globally  by  the  application, 
the  View,  or  whoever  else  might  need  them.  This  global  use  of  the  input  vio¬ 
lates  the  design  of  the  Modifier  class,  which  is  only  intended  to  be  used  by  the 
View  class.  Hopefully  a  design  solution  will  find  a  way  to  handle  input  that  is 
not  reliant  on  global  access  or  the  Modifier,  possibly  with  the  addition  of  an 
Input  class  as  discussed  in  the  pre\'ious  section.  This  approach  would  allow  the 
flags  to  be  kept  in  a  package  by  themselves,  and  this  package  should  clearly 
denote  that  it  is  meant  to  be  used  as  a  global  repository.  Naming  it 
Easj'_Sim.GlobaLFlags  or  a  similar  name  would  at  least  make  its  purpose  dread¬ 
fully  understandable.  The  flags  package  would  also  be  a  textbook  example  of  a 
case  where  a  protected  type  could  be  used  to  guarantee  that  the  many  different 
classes  in  an  application  that  access  the  global  data  do  so  safely. 

Along  the  vein  of  Input  discussions,  the  Standard_lnpui  class  as  cur¬ 
rently  implemented  is  monolithic,  as  ii  contains  functionality  for  the  mouse, 
keyboard,  and  keypad  which  could  a!!  be  separated  into  building  blocks.  This 
disassoclatlon  would  allow  better  modularity  and  flexibility,  as  an  application 
developer  could  choose  to  use  any  combination  of  the  standard  devices. 

The  dependencies  on  Performer  may  be  completely  obscured  in  the  .Ada 
package  specifications  by  liberal  use  of  subtyping.  This  technique  has  been 
demonstrated  by  the  Coords  type,  and  could  be  tnstrumenral  in  making  the  in¬ 
terfaces  for  the  Easy_Sim  framework  platform  independent. 
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Finally,  the  use  of  Finalization  to  perforr..  memorj'  reclamation  when 
dynamically  allocated  objects  are  no  longer  needed  has  not  been  thoroughly 
examined.  Although  this  neglect  was  in  part  due  to  Finalization's  imntatnrG 
implementation  by  GNAT,  this  concept  should  be  used  in  Easy._Sim  so  that 
memory'  management  on  the  heap  is  as  efficient  as  possible. 

This  section  has  described  man}’  areas  in  which  the  implementation  of 
the  Easy_Slm  application  framework  m.lght  be  Improved  by  future  re¬ 
searchers.  The  next  section  tells  the  reader  where  more  information  on 
Easy_Sim  can  be  found,  and  it  concludes  this  thesis. 


7.3  Conclusion 


It  has  been  a  pleasure  to  describe  the  work  done  in  developing  Easy_Sim.  The 


task  was  certainly  challenging  and  rewarding,  and 


fHtnrr  onH  tKo  tKo  rooHor 

MAAW  ^AAW  AAkVWAWOW  K/A  tAiW  AWMWAWL 


is  sincerely  appreciated.  The  code  for  the  Easy_Sim  framework  and  a  version 
of  this  document  are  available  via  anonymous  ftp  from  archive.afit.af.mil  in 
the  pub/jkayloe  directory.  This  directory  can  also  be  accessed  threugh  the 
World  Wide  Web  at  ftp://archlve.afit.af.mil.  If  more  information  is  needed  or 
there  are  any  questions,  please  contact  the  author  directly. 
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